Hello,
I'm new to this list and searched the archive about the last mounted version in the HFS+ Volume Header Block. The spec says that external apps creating or modifying HFS+ volumes should use a creator code in this slot.
Mark Day answered, in a message from april :
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.
When I pass my volume through Norton, I get an error on this precise point.
Who should I believe?
At a guess I'd say Norton is picking up on exactly that point. Yes its great you've used a unique identifier, no Norton doesn't know anything about it, so doesn't no how to react. What should an arbretary piece of software do about a file system wuth an unknown unique identifier? My gut feeling is to treat a unique identifier as if it were apple, unless you know something (ie say symantec started doing stuff, I bet they have a number norton knows about). If Norton haven't implemented it this way, then you'll have to either ignore the error, if you can, (which would be my preference) or lie to norton about who last made changes to the drive. The later would work, but if there are errors in your implementation there is no way for other clever utilities to identify whats yours and whats not.
In short, if you really have to, change the value to something that works quietly.
Simon
Simon,
SB> At a guess I'd say Norton is picking up on exactly that point. Yes SB> its great you've used a unique identifier, no Norton doesn't know SB> anything about it, so doesn't no how to react. What should an SB> arbretary piece of software do about a file system wuth an unknown SB> unique identifier?
Since the spec is so clear, I thought that the author of Norton Disk Doctor would have accepted any value in this slot.
[snip]
SB> In short, if you really have to, change the value to something SB> that works quietly.
The problem is that many users check their media with Norton and whine when it barks. I remember many problems with the bundle bit and with the modification date.
Thanks for your answer.
On Friday, September 20, 2002, at 02:40 AM, Pierre Duhem wrote:
I'm new to this list and searched the archive about the last mounted version in the HFS+ Volume Header Block. The spec says that external apps creating or modifying HFS+ volumes should use a creator code in this slot.
Mark Day answered, in a message from april :
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.
When I pass my volume through Norton, I get an error on this precise point.
Who should I believe?
Me. :-)
The fact that Norton Disk Doctor (or at least some versions) complains about an unrecognized signature is a bug in Disk Doctor. I think they simply misunderstood the purpose of that field when they did their first HFS Plus compatible product.
Mac OS X puts a different signature there than does Mac OS 8/9. And if we ever make any significant changes in the part of the code that handles the on-disk structures, we will probably use yet another signature. Older versions of Disk Doctor complained about the Mac OS X signature, but current versions don't seem to. I don't know whether Disk Doctor now has a list of known signatures, or if they allow any value.
On Friday, September 20, 2002, at 05:42 AM, Pierre Duhem wrote:
Since the spec is so clear, I thought that the author of Norton Disk Doctor would have accepted any value in this slot.
Or at least make it sound less worrisome (a "note" rather than "disk corruption").
The problem is that many users check their media with Norton and whine when it barks. I remember many problems with the bundle bit and with the modification date.
I know what you mean. By all means write up bugs against Disk Doctor if they complain about something they shouldn't. It would certainly be nice if they were clearer about the severity of the inconsistencies they find.
-Mark
Mark,
MD> Mac OS X puts a different signature there than does Mac OS 8/9. And if MD> we ever make any significant changes in the part of the code that MD> handles the on-disk structures, we will probably use yet another MD> signature. Older versions of Disk Doctor complained about the Mac OS X MD> signature, but current versions don't seem to.
On my older 6100, under 8.1, I get "8.10". On my new eMac under OS X, I get "10.0". I still have to upgrade it to Jaguar and will see what gives.
On Thursday, September 26, 2002, at 05:29 AM, Pierre Duhem wrote:
On my older 6100, under 8.1, I get "8.10".
All the way up to Mac OS 9.2.2 use '8.10', though we really should have been changing that as we made significant changes or fixes.
On my new eMac under OS X, I get "10.0". I still have to upgrade it to Jaguar and will see what gives.
Jaguar still uses '10.0'. It arguable that it should have changed the lastMountedVersion, too.
-Mark
Somebody please tell me how to get off this mailing list.
Thanks.
-----Original Message----- From: hfs-user-admin@lists.mars.org [mailto:hfs-user-admin@lists.mars.org] On Behalf Of Mark Day Sent: Thursday, September 26, 2002 2:06 PM To: Pierre Duhem Cc: hfs-user-admin@lists.mars.org; hfs-user@lists.mars.org Subject: Re: [hfs-user] Last mounted version in HFS+
On Thursday, September 26, 2002, at 05:29 AM, Pierre Duhem wrote:
On my older 6100, under 8.1, I get "8.10".
All the way up to Mac OS 9.2.2 use '8.10', though we really should have been changing that as we made significant changes or fixes.
On my new eMac under OS X, I get "10.0". I still have to upgrade it to Jaguar and will see what gives.
Jaguar still uses '10.0'. It arguable that it should have changed the lastMountedVersion, too.
-Mark
Hello,
In the past years, I've seen many times formatting utilities which formatted removable media as floppies, that is, without partition table and with the MBR (signature BR) in the 2nd sector.
When I test such a scheme under Norton Disk Doctor v. 5, the disk passes, with some residual errors.
I'm now testing also under NDD 7 and Disk Utility, under OS X.1.4, and the disk never mounts.
Is such a formatting scheme deprecated?
Under NDD 5, the program complains about the block size (I chose 4KB, as I had noted from other media) and insists on having 512B sectors.
Does this make sense?
Thanks in advance.
4kb is the default block size for HFS+, 512B is the default for HFS. My understanding is that having a device without parition table is the norm for small devices. Are you sure you have HFS support?
Simon
Simon,
SB> 4kb is the default block size for HFS+, 512B is the default for SB> HFS. My understanding is that having a device without parition SB> table is the norm for small devices.
Where does this "default block size" come? In my understanding, the formatter sets the block size in the MBR (or in the VHB for HFS+). I have already seen floppies formatted in HFS with 1024B/sector and they seem to work OK.
On the other hand, I never had a formatter which formatted as a floppy (I used Silver lining, FWB, Apple's own tools, Drivor, Formac's formatter and many others). But I saw many media formatted as floppies.
SB> Are you sure you have HFS support?
Yes. HFS and HFS+, under OS 8.1 and 10.1.4.
Note thought that under HFS+ blocks size can be changed. Under HFS it MUST be 512bytes. Changing it means its not a HFS disk anymore. Perhaps HFS+ requires a partition table. Have a read of Technote TN1150 for more information (regarding HFS+)
Simon
Bonjour Simon,
Le jeudi 26 septembre 2002, à 17:21, vous écriviez :
SB> Note thought that under HFS+ blocks size can be changed. Under HFS SB> it MUST be 512bytes.
I don't think this is true. My formatter computes the block size with a simple division: 1 + (nb_sectors / 0xFFFF). I think I found this formula on some Apple document (Inside Macintosh ?).
SB> Changing it means its not a HFS disk anymore. SB> Perhaps HFS+ requires a partition table. Have a read of Technote SB> TN1150 for more information (regarding HFS+)
I read TN1150 several times along the years, from one of the first editions, in 1999. I didn't read anything about the need of a partition table. That is what one should conclude from reading IM and other documents, but it is never stated so clearly. On the other hand, I already saw many such media.
The default block size is specified in Inside Macintosh: Files page 2-54 and 2-56. It states that the default macintosh block size is 512 bytes. Each device is conceptually a physical and logical device, the physical one being what in linux is a block device (that happens to be a hard disk), logical one being on a per volume basis. All Physical devices are 512 byte blocks, this is stated on 2-54, and discussed further in Inside Macintosh: Devices, SCSI Manager (3-12). All code relating to the partition table, takes place at device level, rather than file system level. This all changed with HFS+
I think the thing you're confusing is logical block size, which is stated as the lowest multiple of 512 such that less than 65535 blocks exist on the volume, and physical block size (always 512). It states (2-54) that the organisation of a floppy disk doesn't include partitions (and hence can't include device drivers), wheras hard disks do. Perhaps this has something to do with it.
This is all fairly academic if you're using HFS+ though, which I think sounds like the best idea.
Simon
On Thursday, September 26, 2002, at 09:01 AM, Pierre Duhem wrote:
Bonjour Simon,
Le jeudi 26 septembre 2002, à 17:21, vous écriviez :
SB> Note thought that under HFS+ blocks size can be changed. Under HFS SB> it MUST be 512bytes.
I don't think this is true. My formatter computes the block size with a simple division: 1 + (nb_sectors / 0xFFFF). I think I found this formula on some Apple document (Inside Macintosh ?).
Um, not sure exactly what you're trying to do but this could be trouble. On HFS the allocation block size was, by default, the smallest multiple of 512 bytes that would make the total number of allocation blocks fit in 16 bits. On HFS+, however, the allocation block size must be a power of two multiple of 512, i.e. 512 bytes, 1K, 2K, 4K, 8K, etc. 3K, for instance, would NOT be a valid allocation block size!
See TN1150 (bottom of page 4).
SB> Changing it means its not a HFS disk anymore. SB> Perhaps HFS+ requires a partition table. Have a read of Technote SB> TN1150 for more information (regarding HFS+)
I read TN1150 several times along the years, from one of the first editions, in 1999. I didn't read anything about the need of a partition table. That is what one should conclude from reading IM and other documents, but it is never stated so clearly. On the other hand, I already saw many such media.
-- Best Regards Pierre Duhem Logiciels & Services Duhem, Paris (France) duhem@macdisk.com
On Thu, 26 Sep 2002, Simon Bazley cum veritate scripsit :
Note thought that under HFS+ blocks size can be changed. Under HFS it MUST be 512bytes. Changing it means its not a HFS disk anymore.
[...]
Just a small note: You can use HFS 512 byte block sizes even if your drive is formatted with other block sizes (i.e. 4k blocks). This is a layer beyond HFS. Don't mix it up! ;-)
OT: Thank you all for the information given on this list (just wanted to say it)!
-- Sending unsolicited commercial email to this address may be a violation of the Washington State Consumer Protection Act, chapter 19.86 RCW. Das Verschicken unverlangter kommerzieller email an diese Adresse ist verboten (LG Traunstein, 2 HK O 3755/97 vom 14.10.1997, CR 1998, 171f).
-
Frank Meurer -
Gary Liu -
Mark Day -
Patrick Dirks -
Pierre Duhem -
Simon Bazley