hfs-user

hfs-user@lists.mars.org

183 discussions

Catalog Thread record size ?
by Entwicklung 16 Apr '02

16 Apr '02

Hello, I just have a question regarding the size of the HFS Plus - Catalog Thread Record specified in the Apple Universal Interfaces headers - typedef UInt16 UniChar; /* HFSUniStr255 is the Unicode equivalent of Str255 */ struct HFSUniStr255 { UInt16 length; /* number of unicode characters */ UniChar unicode[255]; /* unicode characters */ }; /* HFS Plus catalog thread record -- 264 bytes */ struct HFSPlusCatalogThread { UInt16 recordType; /* record type */ UInt16 reserved; /* reserved - set to zero */ HFSCatalogNodeID parentID; /* parent ID for this catalog node */ HFSUniStr255 nodeName; /* name of this catalog node (variable length) */ }; typedef struct HFSPlusCatalogThread HFSPlusCatalogThread; Based on the above declarations shouldn't the size for the HFSPlus catalog thread record be 2+2+4 (since CNID's are 4 bytes long ) + 256*2 = 264+256 instead of 264 as mentioned above ? I think someone probably forgot to multiply the 256 by 2 but I just wanted to make sure that is an error. I'd be happy to hear some feedback from the list wrt this. Best Regards, Nandini Hengen

3 6

hfsutils for HFS+
by Biswaroop(External) 16 Apr '02

16 Apr '02

Hi , Some days back , in this list someone had posted that he is working to enhance the hfsutils for HFS + filesystem. Can i get it?? Waiting for ur answers Bye Biswaroop The difference between sunrise and sunset lies in the freshness of your eyes. --Bisban

2 1

HFS and HFS+ wrapper
by Biswaroop(External) 11 Apr '02

11 Apr '02

Hi everybody, I was going thru all the mails posted by Nandini and Mark giving us information about HFS and HFS+ and wrappers. This is just a inquisitive question. Some days back it was said HFS + has B- trees where as HFS has B* trees. Then in older Macs if we read a filesystem of type HFS+ in a HFS wrapper, do that wrapper also take care for the internal differences in Data structures. A more summary of this wrapper concept would satisfy my interest. Anybody can just give a more basic understanding of this Wrapper and its functionalities would be wonderfull. Wating for them.. Bye Biswaroop The difference between sunrise and sunset lies in the freshness of your eyes. --Bisban

2 1

Index / Leaf nodes - help needed..
by Entwicklung 11 Apr '02

11 Apr '02

Hello Listers, Unfortunately I seem to be stuck again - I tried creating a volume with 601 files. In my case this requires one level of leaf-nodes and 3 levels of index nodes (including the root level ). Of these 601 files I'm not able to read 16 files . My tree looks like this : Root points to IndexNodeA1 and IndexNodeA2. IndexNodeA1 contains pointer records to IndexNodesB1..11 IndexNodeA2 contains pointer records to IndexNodesB12..17 Here's where the problem seems to arise: IndexNodeB16 and IndexNodeB17 contain pointers to leaf-nodes L1..11 and L12..17 each Of these the data present in the leaf-nodes L9,L10 and L11 as well as that present in L15, L16 and L17seems to getting lost. In short the final three pointer records present in the lowest level index node (only in the last 2 of the 17 index nodes however) seems to be getting lost. The funny part is L15 contains 3 catalog-file records of which the first one is again readable but the other two aren't. My point of view: 1. As was mentioned in a previous email, since the leaves are gone thru' first, all the file-icons are displayed correctly on the Mac. Then the index nodes are traversed. 2. The problem cannot lie in the root or A level index nodes since part of the data pointed to by each of the B-level index nodes get dispayed correctly. If there was some mistake in the Ptr records present in level A then one would expect that none of the leaf nodes pointed to by a particular B-level node appear correctly. 3. I also checked the record offsets at the end of the nodes and the keylengths.All my keys are sorted. I don't have any thread records at the moment. Under linux hfsutils seems to be able to read all files present in L15,L16 and L17 without any problem though my Mac refuses to read any other than the first file in L15. (Error -60) I'm in a fix right now since I don't know what this is due to or how exactly to isolate this error. My mode of generating the index nodes is quite generic so I would expect an error to either repeat itself more frequently or no error to appear... I need some professional help from anyone who could take a look at my problem and offer some suggestions. I wanted to attach an image but it is a little large to openly post on the list to everyone. If anyone would like to take a look at it please let me know... would be glad if someone could help. Regards, Nandini

1 0

Re: Fw: [hfs-user] Problems with HFS+ empty volume...
by Entwicklung 11 Apr '02

11 Apr '02

Hello Mark, > myVolHeader.lastMountedVersion=kHFSPlusMountVersion; // > implementation version which last mounted volume You should pick some other constant unique to your implementation. That way, if a bug is found in your implementation, other implementations can check this version to correct for the bug. In my case I've reset kHFSPlusMountVersion to my own unique creator-code registered with Apple (it doesn't hold '8.10' in my case) > myVolHeader.folderCount=0; // number of directories in volume That may be wrong. I can't remember whether the folder count includes the root directory. The HFS+ TN says that it doesn't include the root folder. > myVolHeader.nextCatalogID=0x00000000; // next unused catalog > node ID That number should be at least 16 (the minimum ID for ordinary files and folders). In case of HFS I just played around with these values and set this field to 0. This didn't affect readability in any way and my volume is a read-only medium so no further CNID's will be assigned. This was why I've set it to 0 for HFS+ too... maybe some extra check is being made in case of HFS+ so I'll change this to 16. > myVolHeader.encodingsBitmap[0]=0x00000000; // which encodings > have been used on this volume > myVolHeader.encodingsBitmap[1]=0x00000000; You should probably set at least bit 0 of the first field. That corresponds to the MacRoman encoding, which is the fallback when other encodings don't work. OK.. I'll do that In general, if you're mastering CDs, the physical sector size will be 2048 bytes per sector. You might as well make the allocation block size and clump sizes 2048 as well. That way, one sector is one block, and the math is a little easier. On Mac OS X, performance may be slightly better if the allocation block size is 4096 (the same as its VM page size); of course you'd only do this if you can fit all of your data in 4KB allocation blocks. It's true that the math is a little easier but making the allocation block bigger would not particulary help in space-saving, would it ? In case of a CD of 650MB there isn't much of space-saving in case of HFS+ anyway but after reading the Specs and browsing a number of websites I came to the conclusion that my allocation block size should be 'as small as possible and as large as necessary'. Do correct me if I'm wrong..... In case of HFS I don't have have a choice but for HFS+ it shouldn't be a problem setting the block-size to 512 even for images greater in size than 32MB, should it ? I thought that was the major improvement of HFS+ over 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 In Mac OS 9, use Disk Copy to create a read/write disk image that is at least 32MB. That is the minimum size volume that Mac OS 9 will format as HFS Plus (though it should recognize smaller volumes). I just tried this out ... It works fine for volumes >32MB. Thanks ! Btw. yesterday I also came across a software MacOpener 2000 which creates HFS+ images. After a large no. of searches this was practically the only cross-platform tool I came across which can supposedly read and write HFS+ volumes (not freeware however). I would have probably considered buying it if I hadn't got this bit of info from you.... but maybe someone else on the list can make use of it after all... Regards, Nandini

2 2

Problems with HFS+ empty volume...
by Entwicklung 05 Apr '02

05 Apr '02

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

2 1

Fw: [hfs-user] Problems with HFS+ empty volume...
by Entwicklung 05 Apr '02

05 Apr '02

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 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

1 0

Differences - HFS/HFS+
by Entwicklung 02 Apr '02

02 Apr '02

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'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

2 1

Difference in Data types??
by Biswaroop(External) 02 Apr '02

02 Apr '02

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 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

4 3

Date Offset
by Entwicklung 28 Mar '02

28 Mar '02

Hello Listers, I've calculated the date and time offset between 1904, Jan 1 midnight and 1970 as : time_t offset = (365*66 + 17 ) *24*3600 1. I'd just like to know if my calculations are ok. The 17 accounts for the extra day in the 17 leap years which occur in this interval. 2. I gathered that Mac uses GMT and the standard C-library time.h bases its calculations on UTC. Would this create any further offset to what I'm considering right now ? If so what would it be ? 3. I also gathered that HFS uses local time and HFS plus uses GMT. Would it be a mistake to save up HFS dates as GMT ? In what way could this create problems ? Could anybody who knows more about this please help me out ?.. would be grateful for any tips / suggestions. Regards, Nandini Hengen

2 2

← Newer
1
2
3
4
5
6
7
8
9
...
19
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

hfs-user