Hello Listers, Thanks to the friendly feedback I got I managed to get started off with including an HFS-Wrapper in my code. It seems to work ok now but I'm not too sure... I only have access to an iMac with MacOS 9 - my HFS+ Volume gets displayed but how do I get to verify if the ReadMe I'm creating in the Wrapper is ok ? The volume is recognized as an HFS+ Volume (since the embedded volume seems to be getting mounted directly) and I can do a GetInfo on it. Do I necessarily need an older Mac which doesn't support HFS+ to get to see the ReadMe ?
I have one more question - Is it possible to have a Wrapper for HFS-volumes as well - embedding an HFS-volume within another HFS-Volume ? I guess this wouldn't have any benefits as such but theoretically it should be possible, right ?
-Nandini
**************************************************
The really bad thing about software is debugging it is a real nightmare when you weed one bug out then ten new ones will sprout 'til you get as mad as a march hare
*****************************************************
Hi,
It's probably pretty simple for testing purposes to remove the pointers to the "wrapped" HFS+ volume; the resulting disk image should then be just another HFS disk and you can use all the usual disk verification tools directly on it to see if there are any inconsistencies found. If all is well and you can double-click your "ReadMe" and see what you expect you can be reasonably confident that a user on a non-HFS+-savvy system would see exactly that, too.
Good luck, -Pat Dirks.
On Friday, May 3, 2002, at 01:44 AM, Entwicklung wrote:
Hello Listers, Thanks to the friendly feedback I got I managed to get started off with including an HFS-Wrapper in my code. It seems to work ok now but I'm not too sure... I only have access to an iMac with MacOS 9 - my HFS+ Volume gets displayed but how do I get to verify if the ReadMe I'm creating in the Wrapper is ok ? The volume is recognized as an HFS+ Volume (since the embedded volume seems to be getting mounted directly) and I can do a GetInfo on it. Do I necessarily need an older Mac which doesn't support HFS+ to get to see the ReadMe ? I have one more question - Is it possible to have a Wrapper for HFS-volumes as well - embedding an HFS-volume within another HFS-Volume ? I guess this wouldn't have any benefits as such but theoretically it should be possible, right ? -Nandini
The really bad thing about software is debugging it is a real nightmare when you weed one bug out then ten new ones will sprout 'til you get as mad as a march hare
*****************************************************
Hi, I just tried it - and it works... Thanks for the tip!
Btw. Mark had written sth about Disk First Aid and the alternate volume header - one problem I've been having right from the start is that Disk First Aid is unable to read my CD and Norton Disk Doctor detects 'major problems' on my CD. It seems as though this is due to the runout-blocks being appended to the end of my image i.e. after the sector in which the alternate volume header is present. This doesn't really disturb me too much since the Mac mounts my CD's and reads them without a problem but I'd like to know if there's sth I can do to overcome this.
-Nandini
----- Original Message ----- From: "Patrick Dirks" pwd@apple.com To: "Entwicklung" entwicklung@whengenibk.de Cc: studentdev@lists.apple.com; darwin-development@lists.apple.com; hfs-user@lists.mars.org Sent: Friday, May 03, 2002 11:52 AM Subject: Re: [hfs-user] Wrapper and Readme
Hi,
It's probably pretty simple for testing purposes to remove the pointers to
the
"wrapped" HFS+ volume; the resulting disk image should then be just
another
HFS disk and you can use all the usual disk verification tools directly on
it
to see if there are any inconsistencies found. If all is well and you can double-click your "ReadMe" and see what you expect you can be reasonably confident that a user on a non-HFS+-savvy system would see exactly that,
too.
Good luck, -Pat Dirks.
On Friday, May 3, 2002, at 01:44 AM, Entwicklung wrote:
Hello Listers, Thanks to the friendly feedback I got I managed to
get
started off with including an HFS-Wrapper in my code. It seems to work ok
now
but I'm not too sure... I only have access to an iMac with MacOS 9 - my
HFS+
Volume gets displayed but how do I get to verify if the ReadMe I'm
creating in
the Wrapper is ok ? The volume is recognized as an HFS+ Volume (since the embedded volume seems to be getting mounted directly) and I can do a
GetInfo
on it. Do I necessarily need an older Mac which doesn't support HFS+ to
get to
see the ReadMe ?
I have one more question - Is it possible to have a Wrapper for
HFS-volumes
as well - embedding an HFS-volume within another HFS-Volume ? I guess
this
wouldn't have any benefits as such but theoretically it should be
possible,
right ?
-Nandini
The really bad thing about software is debugging it is a real nightmare when you weed one bug out then ten new ones will sprout 'til you get as mad as a march hare
studentdev mailing list | studentdev@lists.apple.com Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/studentdev
Do not post admin requests to the list. They will be ignored.
On Friday, May 3, 2002, at 08:55 AM, Entwicklung wrote:
Btw. Mark had written sth about Disk First Aid and the alternate volume header - one problem I've been having right from the start is that Disk First Aid is unable to read my CD and Norton Disk Doctor detects 'major problems' on my CD. It seems as though this is due to the runout-blocks being appended to the end of my image i.e. after the sector in which the alternate volume header is present. This doesn't really disturb me too much since the Mac mounts my CD's and reads them without a problem but I'd like to know if there's sth I can do to overcome this.
Remember that the alternate MDB or alternate Volume Header starts 1024 bytes from the end of the volume. So, on a CD with 2048-byte physical sectors, it would start in the middle of the last physical sector. In the case of a wrapped HFS Plus volume, the alternate MDB is 1024 bytes from the end of the volume, and the alternate Volume Header is 1024 bytes from the end of the embedded part of the volume.
The last 512 bytes of the volume (and embedded volume) are reserved for uses outside the filesystem. Apple's manufacturing process uses the space for various things, without having to disturb the actual volume contents.
I don't know much about the low-level data organization on CDs, but I would think that the driver shouldn't include runout blocks as part of the data (i.e. part of the logical device or partition). Might you actually be writing data past the end of your volume?
If you're working with disk images, you could try truncating the image to 1024 bytes past the start of the alternate MDB (or alternate Volume Header for unwrapped HFS Plus volumes). But you still ought to figure out why there is extra data past the logical end of your volume (or why you aren't putting the alternate MDB/VH in the correct spot).
Disk First Aid tries to use the alternate MDB/VH to identify the volume and find the various structures. The idea is that if the first few blocks of the volume have been overwritten, Disk First Aid can find and fix the volume using the alternate structures, and write corrected information back out to the main MDB/VH. Current versions of DFA should try to find the main MDB/VH if it can't find any alternate. Norton Disk Doctor apparently only uses the main MDB/VH to find the volume's structures, and then later compares the alternate to the main copy.
-Mark
Hi,
Remember that the alternate MDB or alternate Volume Header starts 1024
bytes from the end of the volume. So, on a CD with 2048-byte physical sectors, it would start in the middle of the last physical sector. In the case of a wrapped HFS Plus volume, the alternate MDB is 1024 bytes from the end of the volume, and the alternate Volume Header is 1024 bytes from the end of the embedded part of the volume.
Yes, that's the way it is in my implementation too...
The last 512 bytes of the volume (and embedded volume) are reserved for
uses outside the filesystem. Apple's manufacturing process uses the space for various things, without having to disturb the actual volume contents.
I've just set the last 512Bytes to zero - reserved.
I don't know much about the low-level data organization on CDs, but I
would think that the driver shouldn't include runout blocks as part of the data (i.e. part of the logical device or partition). Might you actually be writing data past the end of your volume?
The runout blocks are just present after the data-part and get appended by the driver responsible for writing out the data - starting off at the point where the data ends. The logical part or partition ends 1024Bytes after the start of the alternate volume header as you said.
If you're working with disk images, you could try truncating the image to
1024 bytes past the start of the alternate MDB (or alternate Volume Header for unwrapped HFS Plus volumes). But you still ought to figure out why there is extra data past the logical end of your volume (or why you aren't putting the alternate MDB/VH in the correct spot).
As mentioned - these extra blocks are not data but Disk First Aid apparently mistakes them to be so since it starts checking from the end....Could it be that I'm making a mistake in my allocation bitmap (in the volume header)? .... if my HFS-volume has n sectors(2kB) including the 2kB blocks containing the volume header and alternate volume header, with block size =512Bytes I would have to account for (n-1)*4 if I'm marking all blocks as allocated, right ? Or should it be (n-2)*4 ?
Disk First Aid tries to use the alternate MDB/VH to identify the volume
and find the various structures. The idea is that if the first few blocks of the volume have been overwritten, Disk First Aid can find and fix the volume using the alternate structures, and write corrected information back out to the main MDB/VH. Current versions of DFA should try to find the main MDB/VH if it can't find any alternate. Which are the versions which do this ?
TIA, Nandini
Hi,
1) What do I do if I want to store up my own customized icon for the ReadMe file ? 2) Is this possible at all from another platform like Windows? (using the resource fork of the file to dump my bitmap of the icon perhaps?) 3) Somebody said I would have to necessarily include sth. in the DTDB/DF files which I've copied into my Wrapper from a freshly initialized HFS-Volume on the Mac ? Is this true ? Can one even do without it ?
Where could I find relevant info about using Resource forks ? This has really been a vague topic to me until now. My head is spinning with Bundle bits and Finder flags right now...
Please do help. -Nandini
----- Original Message ----- From: "Patrick Dirks" pwd@apple.com To: "Entwicklung" entwicklung@whengenibk.de Cc: studentdev@lists.apple.com; darwin-development@lists.apple.com; hfs-user@lists.mars.org Sent: Friday, May 03, 2002 11:52 AM Subject: Re: [hfs-user] Wrapper and Readme
Hi,
It's probably pretty simple for testing purposes to remove the pointers to
the
"wrapped" HFS+ volume; the resulting disk image should then be just
another
HFS disk and you can use all the usual disk verification tools directly on
it
to see if there are any inconsistencies found. If all is well and you can double-click your "ReadMe" and see what you expect you can be reasonably confident that a user on a non-HFS+-savvy system would see exactly that,
too.
Good luck, -Pat Dirks.
On Friday, May 3, 2002, at 01:44 AM, Entwicklung wrote:
Hello Listers, Thanks to the friendly feedback I got I managed to
get
started off with including an HFS-Wrapper in my code. It seems to work ok
now
but I'm not too sure... I only have access to an iMac with MacOS 9 - my
HFS+
Volume gets displayed but how do I get to verify if the ReadMe I'm
creating in
the Wrapper is ok ? The volume is recognized as an HFS+ Volume (since the embedded volume seems to be getting mounted directly) and I can do a
GetInfo
on it. Do I necessarily need an older Mac which doesn't support HFS+ to
get to
see the ReadMe ?
I have one more question - Is it possible to have a Wrapper for
HFS-volumes
as well - embedding an HFS-volume within another HFS-Volume ? I guess
this
wouldn't have any benefits as such but theoretically it should be
possible,
right ?
-Nandini
The really bad thing about software is debugging it is a real nightmare when you weed one bug out then ten new ones will sprout 'til you get as mad as a march hare
studentdev mailing list | studentdev@lists.apple.com Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/studentdev
Do not post admin requests to the list. They will be ignored.
On Friday, May 3, 2002, at 01:44 AM, Entwicklung wrote:
Thanks to the friendly feedback I got I managed to get started off with including an HFS-Wrapper in my code. It seems to work ok now but I'm not too sure... I only have access to an iMac with MacOS 9 - my HFS+ Volume gets displayed but how do I get to verify if the ReadMe I'm creating in the Wrapper is ok ? The volume is recognized as an HFS+ Volume (since the embedded volume seems to be getting mounted directly) and I can do a GetInfo on it. Do I necessarily need an older Mac which doesn't support HFS+ to get to see the ReadMe ?
Probably the most convenient way is to change the drEmbedSigWord in the MDB. That will prevent the File Manager from recognizing it as an HFS Plus volume. It you don't want to burn another CD, then just make a disk image (use Disk Copy to make a read/write image so it will be a block-for-block copy) and use some file editor to change the signature. Then mount the image, and you should see the wrapper. If you're planning on verifying the disk using Disk First Aid or Disk Utility, you should also change the signature in the alternate MDB.
I have one more question - Is it possible to have a Wrapper for HFS-volumes as well - embedding an HFS-volume within another HFS-Volume ? I guess this wouldn't have any benefits as such but theoretically it should be possible, right ?
Theoretically, the mechanism could be extended to include embedded things other than HFS Plus. That's the point of the drEmbedSigWord field in the MDB. However, there is no standard for any value other than 'H+', and no implementation that I know of would mount any other embedded volume.
The embedded extent is NOT treated like any old generic partition. Since HFS and HFS Plus volumes are so similar, a single filesystem plug-in handles both kinds of volumes (much like a single plug-in would handle FAT12, FAT16 and FAT32). It is inside that plug-in that the embedded volume is handled. It reads the block where the MDB should be. If it looks like an MDB, and the drEmbedSigWord is set to 'H+', and there is a Volume Header 1024 bytes from the start of the embedded extent, then the volume is recognized as (wrapped) HFS Plus.
-Mark
-
Entwicklung -
Mark Day -
Patrick Dirks