我有一个应用程序，可以将档案解压到 /tmp 中，恢复解压文件的修改和访问时间。有时这些文件和封闭的档案已有多年历史。文件解压后（有时是几分钟或几小时后），解压软件将有选择地使用/修改某些文件。完成后，应用程序将删除解压的文件/树。此操作可以在一天中的任何时间发生（例如，在 cron 运行 tmpwatch 时）。
应用程序时常会因为找不到它知道最近解压过的文件而发疯。我认为发生的事情是，在 atime/mtime 被调整（由应用程序驱动的 unzip 或 tar）到遥远的过去之后，但在应用程序可以访问相关文件之前，tmpwatch 正在进入解压树。由于 tmpwatch 默认查看 atime，因此它会认为该文件已损坏并将其删除。
可以说，解包可以在其他地方进行，或者应用程序可以使用适当的标志来不将时间戳重置为过去。然而，由于各种原因，这两种方法都不可行。
我认为我可以通过指定 --ctime 参数以及 --mtime（以及之前暗示的 --atime）来修改 tmpwatch cron 脚本以将所有这些考虑在内（并就删除文件做出最保守的决定）。不过，我对 tmpwatch 手册页中使用的术语“这些时间中的最大值”有点困惑——我最初的理解（直到我查看了 C 源代码并认为并非如此）是它采用了最大的差异（这意味着它在删除东西时更加自由）。它实际上是指“这些时间中的最新时间”（因此 tmpwatch 将保留刚刚解压的文件，因为它们的 inode 是最近才被触及的）？
答案1
我想说 - 试一试。touch /tmp/test.dat可以随时更改（以 root 身份）。看看 tmpwatch（也可以在命令行上调用）的行为是否符合您的预期。
另一种选择可能是完全禁用 tmpwatch。