使用文件日期/时间作为元数据：可靠吗？

Question

背景：我在自己的目录中有一组文件，我按照文件名的顺序将它们合并到一个文件中。我称它们为t1.txt, t2.txt, t3.txt...我按照整数的顺序合并它们。

情况：出于各种原因，我想摆脱文件名作为以后文件合并操作的元数据。

行动：我正在考虑转移到一个文件合并系统，该系统按文件创建的日期/时间对文件合并进行排序（显然，我必须按照以后合并的顺序创建文件）。

题：

1. 日期/时间排序的文件合并是否可靠？有隐藏的哥特式吗？某些文件的创建间隔仅为十分之一秒，或者更少——这是跟腱愈合吗？

2. 我应该考虑订购合并是否有不同的东西。

日期/时间对我来说似乎很基本。OTH，一开始看起来简单直接的事情往往最终比想象的要复杂。所以我问。

Answer 1

大多数 Unix 系统不跟踪文件创建时间。它们跟踪文件的修改时间，每次写入文件时都会更新。如果文件在创建时按顺序写入（即第一个文件在创建第二个文件之前完全写入）并且稍后不修改，那么修改时间的顺序将与文件创建的顺序相同，但是在更复杂的场景中，这可能不一样。

除了修改时间 (mtime)，任何 Unix 系统上还有另外两个文件时间戳：访问时间 (atime) 和 inode 更改时间 (ctime)。读取文件时会更新访问时间，但某些系统（特别是默认情况下的 Linux）出于性能原因并不总是更新它。当有关文件的某些元数据更改时（名称、权限等；以及在写入文件时更新 inode 更改时间，但不会在读取时更新，即使 atime 更改）。atime 和 ctime 对您都没有用处。

许多历史上的 Unix 系统以一秒的分辨率跟踪文件时间戳。现代 Unix 系统通常有更好的分辨率，但这需要几个参与者注意：

• 您使用的内核必须支持这种更精细的时间分辨率。
• 文件系统必须能够存储这种更精细的时间分辨率。
• 链中的任何组件（例如 NFS 上文件的 NFS 服务器）都必须支持这种更精细的时间分辨率。
• 任何用于复制文件的工具（存档器、网络同步器等）都必须能够保留更精细的时间分辨率，而不仅仅是秒数。
• 读取文件时间的应用程序必须考虑亚秒级分辨率。经典的 Unix 编程接口不支持文件时间戳的亚秒级分辨率，因此应用程序需要使用相对现代的 API（在 POSIX:2008 中标准化- 仍然相对较新，因为它的采用速度不是很快）。

即使链中的每个人都支持纳秒时间戳，如果文件实际上创建的时间间隔不止一个时钟滴答，那么文件也只会有不同的时间戳——仅仅因为内核记录纳秒并不能保证它会注意到在两个文件创建之间经过了超过 1 纳秒：读取时钟需要时间，因此并非一直都在完成。如果您有一个线程打开文件、写入数据并关闭文件，然后再转到下一个文件，那么我认为实际上任何记录亚秒级分辨率的现有系统系统都会写入不同的时间戳，但您正在使用小风险。（当不同的线程写入文件时，即使采用微秒分辨率，时间戳冲突也是可能的——但通常在这种情况下，您将无法依赖任何东西的排序。）

所以这是可能的，而且只要计算机的速度不会比现在快得多，它就是可靠的，前提是您使用的所有工具都支持亚秒级分辨率。但是您会受到时钟故障或您尚未审查过的亚秒时间戳支持工具的支配。我建议依靠文件名，这样会出错。