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