Reputation: 36139
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
Upvotes: 1
Views: 2098
Reputation: 5861
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.
Upvotes: 0
Reputation: 67859
In addition to Carbon FSGetVolumeInfo()
which returns a FSVolumeInfo
containing signature
and filesystemID
fields, there is the Cocoa -getFileSystemInfoForPath:
method of class NSWorkspace
which returns a string representation of filesystem type: e.g., hfs
for HFS+ and msdos
for DOS FAT.
Upvotes: 1
Reputation: 12045
There are two ways to do this:
getattrlist()
to retrieve the ATTR_VOL_SIGNATURE
attribute for the mount path of the volume. 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 using getattrlist
, you'll probably have to just experiment a bit if you want to go the non-Carbon route.
HFS Plus Volume Format reference
Upvotes: 7