哪些操作应该更改目录的修改日期？

Question

我正在编写一个可以备份或合并目录的工具。

文件的修改日期有点简单，但是目录的修改日期呢？

哪些操作被视为对目录的修改？ （然后我会调用操作系统的 API 来执行此操作。）

预期语义根据操作系统和文件系统有何不同？ 它是否由常见的 3rd 方程序持续更新？

常见的第 3 方程序是否依赖于目录修改日期的某种语义？ （例如：增量备份程序会递归到声明相同修改日期的目录吗？）

加法：

这是另一个示例（尽管我希望范围更广）： 当我将一个目录从一个驱动器复制到另一个驱动器时：实际发生的是，首先创建最外层的目录，然后递归地向下添加单个文件。默认情况下，添加的任何目录的最后一个条目将更改该目录的修改日期。结果是每个目录都会有一个全新的修改日期，它几乎没有信息价值（并且与源目录的不同）。一个问题是我们是否希望如此，或者我们是否希望然后将该目录的修改日期更改为与源驱动器上目录的修改日期相同。

Answer 1

您没有指定操作系统或文件系统，它们具有不同的操作，因此出于说明目的，我们将采用POSIX，并且通过“修改时间”，我们假设讨论是关于 mtime (而不是 ctime)。

POSIX 起源于 Unix，就像@itisravi 所说，目录只是另一种类型的文件。

这意味着两件事：

• 每个更改文件 mtime 并且可以在目录上调用的系统调用都可以更改目录的 mtime。
• 每个修改目录 inode 数据内容（即文件名列表或与列表中的文件名关联的 inode 编号）的系统调用都会更改目录的 mtime。

在第一个类别中，我们有 utime(2) 及其变体，例如 futimens(2)。

在第二类中，我们有creat(2)、open(2) with O_CREAT、mkdir(2)、mkfifo(2)、mknod(2)、bind(2) 到一个 unix 域套接字、rename(2)、link(2)、symlink(2)， unlink(2)、rmdir(2) 及其变体。

所有这些指向规范的链接都有相关部分说明何时必须更新 mtime。

他们没有的是关于何时应该不改变mtime的任何规范。这意味着文件系统基本上可以随时将 mtime 更改为它想要的任何内容。为什么要做这样的事情？这里有几个例子：

• 后台任务，例如删除旧文件。
• 管理员将文件系统恢复到旧快照。
• 在不更新 mtime 的情况下无法有效地在后台优化或纠正错误的实施问题。
• NFS silly rename（但请注意 NFS 不符合 POSIX）。

但是，就您正在编写的工具（rsync(1)? 的克隆？）而言，还有其他注意事项：

• 元数据很重要。如果有人 chown 了目录中的文件，它不会改变目录的修改时间，但你仍然需要进入目录并在那里做一些事情。
• 一些工具，例如cp -a 或 Caja，默认情况下会在复制数据时复制元数据。源数据的元数据确实比新建数据的元数据有用得多。
• 当您合并目录时，您需要确定 mtime 设置为的一致定义。可能“两个目录中最新的”是最普遍适用的定义。
• 除了 rsync 之类的备份工具（听起来与您正在做的事情相似）之外，还有另一个对检测更改感兴趣的工具系列 - 构建工具。 make(1) 和 consider modification times 之类的工具，但这是“旧方式”，较新的构建工具会散列它们复制的数据，而 detect changes based on hashes - 您可能需要考虑使用此选项。

Answer 2

当您意识到目录也是文件时很明显，因此任何更改目录内容的内容都会更新其修改时间。由于 dir 的内容是文件名，基本上目录内的任何入口操作（create、mkdir、rmdir、unlink 等）都会更新其 mtime。您还可以使用 utime(2) 系统调用手动设置 atime 和 mtime。

所有这些都适用于 Linux 和各种 Unix 操作系统变体的文件系统。