使用文件日期/時間作為元數據：可靠嗎？
**背景：**我在他們自己的目錄中有一組文件，我按照文件名的順序將它們合併到一個文件中。我稱它們為
t1.txt, t2.txt, t3.txt...我按整數的順序合併它們。**情況：**由於各種原因，我想擺脫文件名作為以後文件合併操作的元數據。
**行動：**我正在考慮轉移到一個文件合併系統，該系統按文件創建的日期/時間排序文件合併（顯然，我必須按照以後合併的順序創建文件）。
問題：
- 日期/時間排序的文件合併是否可靠？有隱藏的哥特人嗎？有些文件的創建時間只有十分之一秒，或者更短——這是致命弱點嗎？
- 訂購合併時我應該考慮什麼不同的東西。
日期/時間對我來說似乎很基礎。OTH，起初看起來簡單直接的事情往往比想像的要復雜。所以我問。
大多數 Unix 系統不跟踪文件創建時間。它們跟踪文件的修改時間，每次寫入文件時都會更新。如果文件在創建時按順序寫入（即第一個文件在創建第二個文件之前已完全寫入）並且以後沒有修改，則修改時間的順序將與文件創建的順序相同，但在更複雜的場景中，這可能不一樣。
除了修改時間 (mtime)，任何 Unix 系統上還有另外兩個文件時間戳：訪問時間 (atime) 和 inode 更改時間 (ctime)。讀取文件時會更新訪問時間，但出於性能原因，某些系統（尤其是預設情況下的 Linux）並不總是更新它。當有關文件的某些元數據（名稱、權限等）發生更改時，inode 更改時間會更新；文件寫入時也會更新，但讀取時不會更新，即使 atime 發生更改。atime 和 ctime 都不會對您有用。
許多歷史上的 Unix 系統以一秒的解析度跟踪文件時間戳。現代 Unix 系統通常具有更好的解析度，但這需要幾個參與者註意它：
- 您使用的核心必須支持這種更精細的時間解析度。
- 文件系統必須能夠儲存這種更精細的時間解析度。
- 鏈中的任何組件（例如用於 NFS 上的文件的 NFS 伺服器）都必須支持這種更精細的時間解析度。
- 任何用於復製文件的工具（存檔器、網路同步器等）都必須能夠保持更精細的時間解析度，而不僅僅是秒。
- 讀取文件時間的應用程序必須考慮亞秒級解析度。經典的 Unix 程式介面不支持文件時間戳的亞秒級解析度，因此應用程序需要使用相對現代的 API（在 POSIX:2008 中標準化——仍然相對較新，因為它的採用速度不是很快）。
即使鏈中的每個人都支持納秒時間戳，如果文件實際上創建的時間間隔超過一個時鐘滴答，文件也只會有不同的時間戳——僅僅因為核心記錄納秒並不能保證它會注意到兩次文件創建之間已經過去了超過一納秒：讀取時鐘需要時間，因此並非一直都在完成。如果您有一個執行緒打開文件，寫入數據並在繼續下一個文件之前關閉文件，那麼我認為實際上任何記錄亞秒級解析度的現有系統系統都會寫入不同的時間戳，但您正在採取一個小風險。（當不同的執行緒正在寫入文件時，即使是微秒級的解析度，時間戳衝突也是可能的——但通常在這種情況下，您將無法依賴任何事情的排序。）
所以這是可能的，只要電腦沒有比現在快得多，它就是可靠的，前提是你使用的所有工具都支持亞秒級解析度。但是您會受到時鐘故障或您沒有審查過的亞秒級時間戳支持的工具的支配。我建議依靠文件名，出錯的可能性較小。