Hello Listers,
I would be grateful to anyone who could just take a look at the following code ( for the HFS+ Volume Header) and let me know if there are any major defects. I'm having a problem detecting the point of failure - the volume contains 0 files or directories and is not even getting mounted.
Could it be that not setting the attributes file and startupfile to anthing is creating some problem ?
I'm probably missing out on something basic here and am not able to …
[View More]proceed...please help if you can.
Regards,
Nandini
HFSPlusVolumeHeader myVolumeHeader;
myVolHeader.signature=kHFSPlusSigWord;
myVolHeader.version=kHFSPlusVersion;// current version is kHFSPlusVersion
myVolHeader.attributes=0x0100; // volume attributes
myVolHeader.lastMountedVersion=kHFSPlusMountVersion; // implementation version which last mounted volume
myVolHeader.reserved=0; // reserved - set to zero
myVolHeader.createDate=VolCrDate; // date and time of volume creation
myVolHeader.modifyDate=VolCrDate; // date and time of last modification
myVolHeader.backupDate=VolCrDate; // date and time of last backup
myVolHeader.checkedDate=VolCrDate; // date and time of last disk check
myVolHeader.fileCount=0; // number of files in volume
myVolHeader.folderCount=0; // number of directories in volume
myVolHeader.blockSize=512; // size (in bytes) of allocation blocks
myVolHeader.totalBlocks=28;/*assuming
allocation block= 512 bytes; number of allocation blocks in volume (includes this header and VBM)*/
myVolHeader.freeBlocks=0; // number of unused allocation blocks
myVolHeader.nextAllocation=0; // start of next allocation search
myVolHeader.rsrcClumpSize=512; // default resource fork clump size
myVolHeader.dataClumpSize=512; // default data fork clump size
myVolHeader.nextCatalogID=0x00000000; // next unused catalog node ID
myVolHeader.writeCount=0x00000000; // volume write count
myVolHeader.encodingsBitmap[0]=0x00000000; // which encodings have been used on this volume
myVolHeader.encodingsBitmap[1]=0x00000000;
for(int i=0;i<32;i++)
myVolHeader.finderInfo[i]=0x00; // information used by the Finder
myVolHeader.allocationFile.clumpSize=512; // allocation bitmap file
myVolHeader.allocationFile.extents[0].blockCount=1;
myVolHeader.allocationFile.extents[0].startBlock=3;
for(i=1;i<8;i++)
{
myVolHeader.allocationFile.extents[i].blockCount=0;
myVolHeader.allocationFile.extents[i].startBlock=0;
}
myVolHeader.allocationFile.logicalSize[0]=0;
myVolHeader.allocationFile.logicalSize[1]=512;
myVolHeader.allocationFile.totalBlocks=1;
myVolHeader.extentsFile.clumpSize=512; // extents B-tree file
myVolHeader.extentsFile.extents[0].blockCount=4;
myVolHeader.extentsFile.extents[0].startBlock=4;
for(i=1;i<8;i++)
{
myVolHeader.extentsFile.extents[i].blockCount=0;
myVolHeader.extentsFile.extents[i].startBlock=0;
}
myVolHeader.extentsFile.logicalSize[0]=0;
myVolHeader.extentsFile.logicalSize[1]=512*4;
myVolHeader.extentsFile.totalBlocks=4;
myVolHeader.catalogFile.clumpSize=512; // catalog B-tree file
myVolHeader.catalogFile.extents[0].blockCount=4*4;
myVolHeader.catalogFile.extents[0].startBlock=myVolHeader.extentsFile.extents[0].startBlock+4;
for(i=1;i<8;i++)
{
myVolHeader.catalogFile.extents[i].blockCount =0;
myVolHeader.catalogFile.extents[i].startBlock=0;
}
myVolHeader.catalogFile.logicalSize[0]=0;
myVolHeader.catalogFile.logicalSize[1]=512*4*4;
myVolHeader.catalogFile.totalBlocks=4*4;
myVolHeader.attributesFile.clumpSize=512; // extended attributes B-tree file
for(i=0;i<8;i++)
{
myVolHeader.attributesFile.extents[i].blockCount=0;
myVolHeader.attributesFile.extents[i].startBlock=0;
}
myVolHeader.attributesFile.logicalSize[0]=0;
myVolHeader.attributesFile.logicalSize[1]=0;
myVolHeader.attributesFile.totalBlocks=0;
myVolHeader.startupFile.clumpSize=512; // boot file
for(i=0;i<8;i++)
{
myVolHeader.startupFile.extents[i].blockCount=0;
myVolHeader.startupFile.extents[i].startBlock=0;
}
myVolHeader.startupFile.logicalSize[0]=0;
myVolHeader.startupFile.logicalSize[1]=0;
myVolHeader.startupFile.totalBlocks=0;
----- Original Message -----
From: Entwicklung
To: hfs-user(a)lists.mars.org
Sent: Thursday, April 04, 2002 3:44 PM
Subject: [hfs-user] Problems with HFS+ empty volume...
Hello Listers,
I just wanted to check if anyone knows if it is essential to have an empty B-Tree for the attribute and startup file in an HFS+ image. In case of HFS these weren't present in my image. In case of HFS+ I've increased the node size of the catalog to 4kB and included the other changes as discussed. Only thing I haven't done is to create a B-Tree for the attributes file and the start up file - in short I'm not writing anything into the image for these and have set the respective extents, sizes setc. to 0 in the Volume Header. Is this right or should these be present in the image as 'empty' B-Trees ???
I'm right now creating an empty volume with 0 contents but just the basic structures needed (the way I started off for HFS). The only problem is that I don't have any utilities to create sample HFS+ images which I can cross-check my image with.... Disk Copy on my iMac with MacOS 9 creates only HFS-Volumes by default and Norton Disk Doctor on my Mac recognizes the volume as MacOS Extended but doesn't really bring me any further (since my Mac is unable to mount the volume). There seems to be a hfsplus reader on Sourceforge since the end of last year but I need something like a sample hfsplus writer. Any idea if sth like this exists on the Mac or on other platforms. My Mac has just a CD-drive (no writer) and no floppy drive which make file transfer as cumbersome as it can get.
Any idea why this fails ? Would be glad for any suggestions/tips...
Regards,
Nandini
[View Less]
Hello listers,
I'm trying to extend an HFS-volume to an HFS+ volume. Going by the specifications I've gathered the major differences which would play a role in the construction of an image.....
1) Difference in Allocation Block Size
2) Difference in basic structure of B-Tree components , MDB Vs. Volume Header etc. (incl. respective fields, kind of fields etc.)
3) Difference in NodeSize of the catalog
4) Thread records must be maintained even for files in HFS+
Anything else I'…
[View More]ve left out / overlooked ?
All I want to achieve is to modify my algos for HFS to work for HFS+ as well . I guess the variation in the allocation block size would help optimize disk space for HFS+.
Any other major / minor aspect I should be considering ?
Regards,
Nandini
[View Less]
HI, Everybody
Wishing u all a very Happy Holi.( An Indian festival played
with colours)
Well in the MDB structure for an HFS volume the
field
vol.drXTClpSiz /* clump size for extents overflow file */
is 4 bytes long.
Again in the Catalog Data Record structure the member
filClpSize; /* file clump size */
takes 2 bytes.
Therefore when i assign the value of the first variable to
the second I lose information.
But then one way is to make the MDB's variable contain
a …
[View More]value only for 2 bytes then assignment won't make
a data loss. But the value for the MDB's variable was
calculated as 1/128 th part of the Total volume size.
An emphirical formula used in the hfsutils package.
Any comments on this???
Please is there any simple formula to find out the
extent file size and the catalog file size for a volume
when we know before hand how many files have to be
in that volume.
For eg. if i know i have to write "X" files contained in
"Y" number of directories.
Then can i calculate what should be the volume's
clump size for the extents overflow file and the catalog
file.
Waiting for ur explanations.
Bye
Biswaroop
Each Day gives us an Opprutunity to
Ruin it, those who Fail, Succeed in Life.
-- Bisban
[View Less]