什麼是資源叉子在Mac OS X? 如何才能使用? 哪些應用程序正在使用他們呢?難道他們被廢棄? 是鼓勵開發利用他們呢? 他們的未來嗎?為什麼會出現一個缺乏現代化的最新文件? 這些只是一小部分的問題,我對基本的Mac OS X的文件系統。 我花了幾個小時,數百人的谷歌查詢只返回與衝突的信息。 一個過程的拾荒從數以百計的電子郵件信息在郵件列表和新聞組論壇,翻看過時的文件,並動手實驗我成立了一個粗略的了解這項技術。 以下是我編譯的意見可能會或可能不正確。
我寫這個假設下,目標系統運行中的問題的HFS +文件系統 。
擴展屬性與資源叉
首先,我現在一摘自維基百科頁面上資源叉 :
資源叉就是建構的Mac OS操作系統使用結構化數據存儲在一個文件中,伴隨著非結構化數據存儲在數據叉。
從我所收集的,有明顯的差異資源叉和擴展屬性在一個點。 然而,這似乎不再是這樣,因為我將試圖解釋下一節。 總之,詞彙的使用已成為更加難以捉摸,這似乎是最混亂的源頭。
資源福克斯正在過時
有相當多的資源派生噪聲說是要走了。 根據有關資料,我發現,這種說法只是部分正確。 事實上,資源叉已被淘汰的方式默默地改變蘋果底層 API實現。 而這些信息以前存儲在資源派生,它現在已經轉移到數據叉。 據我所知道的,現在大部分這些數據體現在“資源”的目錄,可以發現在應用程序包。 但是,仍然有更多的資源派生數據,這是現在存儲為擴展屬性項中“com.apple.ResourceFork。”
在這一點上我必須插入,看來 Mac OS X的繼續支持命名叉子。 似乎沒有受到任何限制的數量或大小,這些可能,但我不知道任何應用程序利用它們。 大多數人看來是元數據包含在擴展屬性樹。 此元數據是關鍵,價值為基礎,通常非常小的尺寸。
下面是一個無序列表我的意見。
- 蘋果公司的資源叉純粹是許多不同福克斯的Mac OS X的文件系統可以明顯處理。
- 蘋果的資源叉死了,但
- 蘋果的API為互動與資源叉現在存儲這些信息為擴展屬性(com.apple.ResourceFork),而不是使用一個單獨的分支。
- Mac OS X的繼續支持命名叉子。
- 我沒有看到任何應用程序(蘋果或其他方式),使用一個名為叉超出了原來的資源叉。
- 擴展屬性是蘋果產品的廣泛使用。
訪問擴展屬性(EA)和從而com.apple.ResourceFork
為蘋果提供了一個API接口與擴展屬性,但它們可以被訪問,而無需編寫的應用程序通過使用終端和xattr命令。 例如,xattr磷com.apple.ResourceFork的example.txt將顯示數據的com.apple.ResourceFork屬性[如果存在]。 使用@選項的ls命令會給你列出所有的屬性鍵為每個文件[如:ls - la的@]。
一個絕招兒是仍然可以在Mac OS X Leopard的[1050]從日子ResourceFork被儲存在自己的叉子使用..namedfork / rsrc。如果你不提供一個名稱為叉,那麼它默認為蘋果的ResourceFork。 例如, 貓的example.txt /秩和比 C將產生同樣的輸出xattr - P的com.apple.ResourceFork的example.txt。
抓把柄!
文件大小計算,不包括終端的規模擴展的屬性,包括ResourceFork。 這必須通過其他方式獲得獨立。 例如,使用..namedfork / rsrc。
清除泥土
我希望這篇文章雞舍一些輕的情況。 擴展屬性是使用相當多的蘋果產品。 例如,聚光燈意見存儲為擴展屬性的鍵值對。 當一個文件被刪除,使用搜尋引擎,一鍵值對書面指示該文件提出的。 時間機器使用擴展屬性來跟踪備份,並且列表可以繼續。
擴展屬性不應該害怕,是一個偉大的方式來存儲額外的元數據。 不幸的是,支持擴展屬性不是無處不在。 即使是一些蘋果電腦公司的捆綁命令行程序不充分或正確地支持擴展屬性。 因此,從編程的角度來看這可能是明智的,避免使用擴展屬性,除非該數據是暫時的。 任何重要的數據應與該文件一起存儲在數據叉。
這裡的希望,電子藝界支持提高在不久的未來!
請發表評論,如果我所收集的資料不正確,或可以更好地澄清。














comments… read them below or add one } (2意見...閱讀下面他們或者添加一 )
是否有任何這方面的資源優勢叉/數據派生的方面超過蘋果操作系統但窗戶做呢?
我還沒有真正探索NTFS備用數據流,所以我做了一個快速搜索和跑過下面的文章,你可能會覺得有趣: http://www.symantec.com/connect/articles/what-you-need-知識有關,另類數據流的窗口
我沒有花任何時間使用ADS於 Windows,但我發現蘋果的實施不太理想。 例如,並非所有公用事業都知道或正常使用的擴展屬性。 舉例來說,rsync的版本附帶 OS X沒有包括完整的支持(3修復 rsync的這個)。 這可能源於一個事實是,並非所有的GNU / BSD的事業支持xattr,至少現在還沒有。
他們是這兩種方法在解決元數據問題。 不幸的是,似乎有一些不確定性,他們(他們明天要來這兒?)。 我設想一個理想的普遍性文件系統元數據管理的結合,大大提高互操作性,這是不現實的,但在未來的5年。 更可以實現的目標將是要么放棄這想法完全或充分納入到文件系統的功能和API的一個可插拔轉換層之間移動文件系統,使無縫。