hfs-user April 2002

hfs-user@lists.mars.org

8 participants
23 discussions

Re: pdf files on Mac-OS 9
by Entwicklung 20 Apr '02

20 Apr '02

Hello, My problem is solved now ... I realised it had to have something to do with the folder threads - i.e. that the thread records didn't maintain correct references to the folders.... was quite a silly error actually .... the nodename[0] field which holds the length of the nodename (in the folder and its thread didn't correspond to each other due to a small bug in my program) ... so though the file and the icon got displayed correctly and the data could be accessed, acrobat apparently tries relocating its way down the tree starting from root. One surprising thing I noticed is that I didn't have this problem for jpg files - probably the graphics application which is launched on Mac OS functions slightly differently as compared to Acrobat..... dunno in what way although...good news is it works now anyway ! Regards, Nandini Hengen ----- Original Message ----- From: "Steve Sisak" <sgs-lists(a)codewell.com> To: "Entwicklung" <entwicklung(a)whengenibk.de>; <darwin-development(a)lists.apple.com> Sent: Friday, April 19, 2002 2:14 PM Subject: Re: pdf files on Mac-OS 9 > At 1:23 PM +0200 4/19/02, Entwicklung wrote: > >What could this be due to ? Could this be some problem with the filesystem > >format or does it rather have to do with Acrobat Reader for Mac OS? > > This is not a Darwin issue, but it's probably that the HFS file type > is not set to and therefor the file can't be opened by Acrobat > because it isn't recognized as a PDF file. > > When you copy the file, PC File Exchange treats it as a Non-Mac file > (because the type isn't set) and applies a type/creator based on the > file's extension which allows the copy to be opened by Acrobat -- it > probably doesn't matter where you copy. > > (Note that the creator is not important, but most pre-X Mac > applications will not open a file with an incorrect type -- > extensions have no significance pre-X) > > -Steve > _______________________________________________ > darwin-development mailing list | darwin-development(a)lists.apple.com > Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development > Do not post admin requests to the list. They will be ignored.

1 0

pdf files on Mac-OS 9
by Entwicklung 19 Apr '02

19 Apr '02

Hello Listers, I have a CD-Volume (HFS) with two levels of files in a directory i.e. at the topmost level (under root) and inside a directory present in root. The same pdf file when present at the higher level is readable directly from the CD but the file present within the directory is not. This problem arises only for Acrobat reader documents.. it works fine for text fíles.... besides dragging and droppping these lower level files onto my desktop from the CD enables me to read them as required. What could this be due to ? Could this be some problem with the filesystem format or does it rather have to do with Acrobat Reader for Mac OS? Any tips would be appreciated. Regards, Nandini Hengen

1 0

Help needed...
by Entwicklung 18 Apr '02

18 Apr '02

Hello listers, I've encountered a problem in my HFS directory structure which I have tried to elaborate below... please do take a look at it and see if some plausible reason strikes you. I have a file File-X say under Root. Under Root I also have a folder Folder-X inside which I have another file of the same name i.e. File-X and another file File-Y. File-X is a pdf file of size 42MB and File-Y is a simple text file only 4kB in size. All icons get correctly displayed from my CD so I presume all the leaf nodes of my catalog B-Tree are getting iterated through (since the icons get set based on the filetype and creator fields). The problem I'm facing is that File-Y (within Folder-X) is readable, File-X under Root is readable but when I try to open File-X which is under Folder-X Acrobat seems to go into sleep mode. What could this possible be due to ? I first thought the references maintained to the file extents (or file size) was wrong... but it seems to be right... the start block as well as the block count (in the leaf nodes) seem to be all right... what else could cause the icon to get displayed but not allow the file to be opened ? - The file is correctly written (twice at two different locations) and readable the first time. - The start-block and block count seems to be right for both. - Another file written at the same level is readable. Could it have something to do with the size of the file ? Please help if you have any idea what could be causing this.. Regards, Nandini Hengen

1 0

HFS+ volumes : kHFSVolumeUnmountedBit
by Entwicklung 18 Apr '02

18 Apr '02

Hello Listers, The HFS+ tech. notes say that the 'Volume attributes' field in the volume header has to have Bit 8 set to 1 if the volume was correctly flushed when it was mounted or ejected the last time. It also mentions that if this is not done it could take an annoyingly long time for the ROM-based consistency check (on Mac OS 7.6 and higher) for boot volumes. 1) My volume is not a boot volume. 2) I have cleared this bit - set it to 0 3) Inspite of 1) and 2) a smaller HFS+ volume with only one index node = root gets mounted pretty fast. 4) A larger HFS+ volume (2 levels of index nodes) doesn't get mounted at all... my iMac with MacOS 9 just hangs altogether..... I have to remove my CD by force and restart. I assumed this couldn't be an error in the catalog but has something to do with the Volume Header since I would have expected to see an error dialog instead. Besides this seems to be HFS+ specific since I never encountered this kind of problem with HFS. Does anyone know what this could be due to ? Any suggestions/comments would be greatly appreciated. Regards, Nandini Hengen

1 1

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

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