IOKit 和 DiskArbitration 框架可以告诉我很多关于 Mac 上挂载卷的信息,但它们似乎无法区分 HFS+ 和 HFS 标准卷。
IOKit/DA 键Content
,对于 HFS 标准卷和 HFS+ 卷,始终是 Apple_HFS 和 hfs DAVolumeKind
。DAMediaContent
diskutil 和 DiskUtility.app可以区分,但我似乎没有被 Apple 开源。
ps statfs(2) 不区分
IOKit 和 DiskArbitration 框架可以告诉我很多关于 Mac 上挂载卷的信息,但它们似乎无法区分 HFS+ 和 HFS 标准卷。
IOKit/DA 键Content
,对于 HFS 标准卷和 HFS+ 卷,始终是 Apple_HFS 和 hfs DAVolumeKind
。DAMediaContent
diskutil 和 DiskUtility.app可以区分,但我似乎没有被 Apple 开源。
ps statfs(2) 不区分
有两种方法可以做到这一点:
getattrlist()
检索ATTR_VOL_SIGNATURE
卷的安装路径的属性。 signature
返回结构的字段。卷的签名是一个 16 位的值,通常解释为两个 ASCII 字符。HFS 的签名是'BD',HFS+ 是'H+',区分大小写的HFS+ 是'HX'。
手册页getattrlist
说该字段是 u_int32,但 FSVolumeInfo 结构中的等效字段只有 16 位,所以我不确定 32 中的哪 16 位在使用时用签名填充getattrlist
,你可能会有如果您想走非碳路线,请尝试一下。
除了FSGetVolumeInfo()
返回FSVolumeInfo
包含字段signature
和filesystemID
字段的 Carbon 之外,还有一个类的 Cocoa-getFileSystemInfoForPath:
方法,NSWorkspace
它返回文件系统类型的字符串表示:例如,hfs
对于 HFS+ 和msdos
对于 DOS FAT。
如果您尝试直接读取分区映射,您可能会遇到的另一个问题是,从历史上看,HFS+ 卷嵌套在 HFS 包装器中。这样做是为了让任何尝试使用具有较旧操作系统的 HFS+ 磁盘的人都会在驱动器上看到一个文件,说明他们所有其余数据的位置。