IOKit和DiskArbitration框架可以告诉我很多有关在Mac上装入卷的信息,但它们似乎无法区分HFS +和HFS标准卷。区分HFS +和HFS标准卷
由于IOKit/DA键Content
,DAVolumeKind
和DAMediaContent
总是Apple_HFS和两个HFS标准和HFS +卷HFS。
diskutil和DiskUtility.app 可以通过来区分,但是我似乎并没有开源苹果。
p.s.的statfs(2)不区分
IOKit和DiskArbitration框架可以告诉我很多有关在Mac上装入卷的信息,但它们似乎无法区分HFS +和HFS标准卷。区分HFS +和HFS标准卷
由于IOKit/DA键Content
,DAVolumeKind
和DAMediaContent
总是Apple_HFS和两个HFS标准和HFS +卷HFS。
diskutil和DiskUtility.app 可以通过来区分,但是我似乎并没有开源苹果。
p.s.的statfs(2)不区分
有两种方法可以做到这一点:
getattrlist()
来检索卷的安装路径ATTR_VOL_SIGNATURE
属性。signature
字段。卷的签名是一个16位值,通常被解释为两个ASCII字符。 HFS的签名是'BD',HFS +是'H +',区分大小写的HFS +是'HX'。
getattrlist
的手册页说该字段是u_int32,但FSVolumeInfo结构中的等效字段仅为16位,所以我不确定在使用getattrlist
时,32位中的哪个16位被填充了签名如果你想要走非碳路线,你可能只需要尝试一下。
HFS Plus Volume Format reference
除了碳FSGetVolumeInfo()
返回包含signature
和filesystemID
字段FSVolumeInfo
,存在NSWorkspace
类的可可-getFileSystemInfoForPath:
方法,它返回文件系统的字符串表示键入:例如,HFS +的hfs
和DOS FAT的msdos
。
如果您直接阅读分区映射,您可能遇到的另一个问题是,历史上,HFS +卷嵌套在HFS包装中。这样做是为了让任何尝试使用带有较旧操作系统的HFS +磁盘的人都能在驱动器上看到一个文件,说明其所有其余数据的位置。
我用getattrlist去了,因为我不喜欢用碳链接,并且可以报告如下:低16位被填充并且HFS标准 - > BD,HFS + - > H +但是,令人惊讶的是,ntfs,fat32 - > BD和HFSX - > H +(不是HX)。奇怪,是吧?不过,涵盖了我的情况。谢谢。 – 2008-10-12 15:25:58