背景：我在自己的目录中有一组文件，我按照文件名的顺序将它们合并到一个文件中。我称它们t1.txt, t2.txt, t3.txt...为按整数顺序合并它们。
情况：由于各种原因，我想摆脱文件名作为以后文件合并操作的元数据。
行动：我正在考虑迁移到一个文件合并系统，该系统按文件创建的日期/时间（显然，我必须按照稍后合并的顺序创建文件）。
问题：
日期/时间排序的文件合并可靠吗？是否有隐藏的哥特查？有些文件的创建间隔只有十分之一秒或更短——这是一个致命伤吗？
对于排序合并，我应该考虑一些不同的事情吗？
日期/时间对我来说似乎很简单。 OTH，一开始看起来简单直接的事情往往最终会比想象的更复杂。所以我问。
答案1
大多数 Unix 系统不跟踪文件创建时间。它们跟踪文件的修改时间，每次写入文件时都会更新该修改时间。如果文件在创建时是按顺序写入的（即第一个文件在创建第二个文件之前已完全写入）并且之后没有修改，则修改时间的顺序将与文件创建的顺序相同，但是在更复杂的场景中，这可能不一样。
除了修改时间 (mtime) 之外，任何 Unix 系统上还有另外两个文件时间戳：访问时间 (atime) 和 inode 更改时间 (ctime)。读取文件时会更新访问时间，但出于性能原因，某些系统（特别是默认情况下的 Linux）并不总是更新它。当有关文件的某些元数据（名称、权限等）更改时，inode 更改时间会更新；写入文件时也会更新，但读取文件时不会更新，即使 atime 更改也是如此。 atime 和 ctime 对您都没有用。
许多历史上的 Unix 系统都以一秒的分辨率跟踪文件时间戳。现代Unix系统往往有更好的分辨率，但这需要几个参与者注意：
- 您使用的内核必须支持这种更精细的时间分辨率。
- 文件系统必须能够存储这种更精细的时间分辨率。
- 链中的任何组件（例如 NFS 上文件的 NFS 服务器）都必须支持这种更精细的时间分辨率。
- 任何用于复制文件的工具（存档器、网络同步器等）都必须能够保留更精细的时间分辨率，而不仅仅是秒。
- 读取文件时间的应用程序必须考虑亚秒分辨率。经典的 Unix 编程接口不支持文件时间戳的亚秒级分辨率，因此应用程序需要使用相对现代的 API (POSIX:2008 标准化- 仍然相对较新，因为它的采用不是很快）。
即使链中的每个人都支持纳秒时间戳，文件只有在实际创建的时间间隔超过一个时钟周期时才会具有不同的时间戳 - 仅仅因为内核记录纳秒并不能保证它会注意两个文件创建之间已经过去了超过一纳秒：读取时钟需要时间，因此并非始终完成。如果您有一个线程打开文件，写入数据并关闭文件，然后再继续处理下一个文件，那么我认为实际上任何记录亚秒分辨率的现有系统都会写入不同的时间戳，但您正在采取风险很小。 （当不同的线程写入文件时，即使采用微秒分辨率，时间戳冲突也是可能的 - 但通常在这种情况下，您将无法依赖任何顺序。）
因此，只要计算机的速度不比现在快太多，这是可能的，而且它是可靠的，前提是您使用的所有工具都支持亚秒级分辨率。但是，您会受到时钟故障或您未审查亚秒时间戳支持的工具的影响。我建议依赖文件名，这样出错的可能性就比较小。
答案2
atime ctime 还是 mtime ？
要记住哪个是哪个：阅读它们的字母顺序
- atime可以单独更新
- ctime将更新atime
- mtime 将更新 atime 和 ctime。
系统可以通过使用 mtime 来伪造 atime 或 ctime。 （懒惰）