跟蹤文件隨着時間的推移

我的想法是要及時跟蹤文件系統上的特定文件，隨着時間的推移兩點之間，T1和T2。這裏的重點在於將文件視爲文件系統上的獨特實體。一個可以改變數據和屬性，但仍然保持其獨特的身份。跟蹤文件隨着時間的推移

的最終目標是要確定是否一個文件的數據具有（不情願）T1和T2之間改變，以通過捕獲和在T1記錄數據散列和創建/文件的修改的屬性，並將它們與所述比較等同於T2。如果所有屬性都保持不變，但哈希不驗證，我們可以說有問題。在所有其他情況下，我們可能願意說改變後的哈希值是修改後的結果，哈希值和未改變的修改值是根據文件（數據）完全沒有改變的結果。

現在，有幾種方法引用文件和相應的缺點：

的文件路徑：但是，如果文件移動到不同的位置，此方法將失敗。
文件數據的數據散列：即使指針已被移動到不同的目錄，也會允許找到文件，或者（或者）指向磁盤上文件數據的指針，但數據無法更改，或者此方法也失敗。

我的想法是在T1檢索特定文件的fileid跟蹤文件在T2，即使它已經改變了它的位置，因此不需要在被看作是一個新文件。

我知道的兩種方法pywin優惠。 win32file.GetFileInformationByHandle()和win32file.GetFileInformationByHandleEx()，但它們顯然只限於特定的文件系統，打破了跨平臺兼容性，擺脫了通用方法來跟蹤文件。

我的問題很簡單：是否有任何其他的想法/理論來跟蹤文件，最好翻過平臺/ FSS？

任何頭腦風暴的思想是值得歡迎的！

來源

2013-03-27 bossi

如何考慮的文件內容MD5哈希值。並通過不同的時間檢查md5哈希？ – 2013-03-27 04:03:20

在linux文件系統上（我想是'ext'），如果我沒有弄錯的話，inode會在文件移動時保持不變。在窗戶上，但是......我不確定。這是一個很好的問題。您可能需要編寫一些特定於平臺的代碼，並涵蓋所有基礎。 – mpen 2013-03-27 04:05:30

@SidharthShah：他報道過。如果文件移動*和*在T1和T2之間修改，則會被擰緊。散列會有所不同;您將無法再找到該文件。 – mpen 2013-03-27 04:06:18

這不是一般的真正可行的，因爲文件身份的想法是一種幻想（類似物理身份的錯覺，但是這是不是一種哲學論壇）。

不能使用文件內容跟蹤的身份，因爲內容的變化。
無法通過附加到文件的任何其他屬性跟蹤，因爲很多文件編輯將通過刪除舊文件，並創建一個新的保存更改。

版本控制系統有三種方式處理這個問題：

（CVS）不跟蹤移動操作。
（Subversion）的軌道移動手動操作。（Git）使用試探法將操作標記爲基於文件內容更改的「移動」操作（例如，如果新文件與現有文件的差異小於50％，則將其標記爲複印件）。

事情是這樣的索引節點號不穩定，不被信任。在這裏，你可以看到，編輯文件，Vim會改變inode編號，我們可以用stat -f %i檢查：

 
$ touch file.txt 
$ stat -f %i file.txt 
4828200 
$ vim file.txt 
...make changes to file.txt... 
$ stat -f %i file.txt 
4828218

來源

2013-03-27 04:10:20

夢幻般的答案，謝謝。我沒有考慮的一個很好而且非常明顯的一點是許多應用程序會將文件的數據重新寫入刪除前者的新文件。看看其他版本控制系統如何處理這個問題，我會研究Git的啓發式方法，看看它是否可以應用於任意數據，文本和二進制文件。從一開始就信任並依賴文件ID/inode似乎有風險。 – bossi 2013-03-27 04:34:21

跟蹤文件隨着時間的推移

回答

相關問題