IOKit and the DiskArbitration framework can tell me a lot of things about mounted volumes on a mac, but they don't seem to be able to differentiate between HFS+ and HFS Standard volumes.
The IOKit/DA keys Content
, DAVolumeKind
and DAMediaContent
are always Apple_HFS and hfs for both HFS Standard and HFS+ volumes.
diskutil and DiskUtility.app can tell the difference, but I they don't seem to have been open sourced by Apple.
p.s. statfs (2) does not differentiate
-
There are two ways to do this:
- Use
getattrlist()
to retrieve theATTR_VOL_SIGNATURE
attribute for the mount path of the volume. - Use the Carbon call FSGetVolumeInfo() and look in the
signature
field of the returned struct.
The signature of a volume is a 16 bit value, usually interpreted as two ASCII characters. The signature for HFS is 'BD', HFS+ is 'H+', and case sensitive HFS+ is 'HX'.
The man page for
getattrlist
says the field is a u_int32, but the equivalent field in the FSVolumeInfo struct is only 16 bits, so I'm not sure which 16 bits of the 32 are filled in with the signature when usinggetattrlist
, you'll probably have to just experiment a bit if you want to go the non-Carbon route.HFS Plus Volume Format reference
Rhythmic Fistman : I went with getattrlist because I didn't feel like linking in carbon, and can report the following: the lower 16 bits are filled in and HFS Standard -> BD, HFS+ -> H+ BUT, surprisingly, ntfs,fat32 -> BD and HFSX -> H+ (not HX). Weird, huh? Still, covers my case. Thanks.mouviciel : In the FSVolumeInfo struct there is also a 16bit filesystemID whose value is 0 for HFS+ and 18771 for DOS FAT. I am still looking for something like an enum in a header file which would give all relevant values. - Use
-
In addition to Carbon
FSGetVolumeInfo()
which returns aFSVolumeInfo
containingsignature
andfilesystemID
fields, there is the Cocoa-getFileSystemInfoForPath:
method of classNSWorkspace
which returns a string representation of filesystem type: e.g.,hfs
for HFS+ andmsdos
for DOS FAT. -
The other problem you can run into should you ever try your hand at reading partition maps directly is that, historically, HFS+ volumes were nested inside HFS wrappers. This was done so that anyone trying to use an HFS+ disk with an older OS would see a single file on the drive explaining where all the rest of their data was.
0 comments:
Post a Comment