我有一个应用程序，解压到/ tmp档案，恢复提取的文件的修改和访问时间。 有时这些文件和封装的存档已经有很多年了。 文件解压后（有时需要几分钟或几小时），解压缩软件将select性地使用/修改一些文件。 一旦完成，应用程序将删除提取的文件/树。 这个操作可以在一天中的任何时候发生（例如，当tmpwatch由cron运行的时候）。
每隔一段时间，应用程序就会因为找不到最近解压缩的文件而吓坏了。 我认为正在发生的事情是，在调整时间/时间（通过由应用程序驱动的解压缩或tar）到远处的过去之后，但在应用程序可以访问相关文件之前，tmpwatch正在下降到解压缩的树中。 由于tmpwatch在默认情况下正在查看，它认为该文件是破旧的，并将其删除。
可以说，解压缩可以在其他地方完成，或者应用程序可以使用适当的标志来不重置时间戳到过去。 但是，由于各种原因，这两种方法都不可行。
我想我可能会修改tmpwatch cron脚本，将所有这些考虑在内（并对删除文件做出最保守的决定），方法是指定–ctime参数以及–mtime（以及之前暗示的 – -atime）。 尽pipe我在tmpwatch手册页中使用了“这些时间的最大值”这个术语，但我有点困惑 – 我的初读（直到我看了一下C源文件，并认为不然）是，它花了最大的差异这意味着它在删除东西时更加自由）。 这实际上是否意味着“最新的这些时间”（因此tmpwatch将离开文件，因为它们的inode只是最近才被打开，只是解压缩）？
我会说 – 试一试。 touch /tmp/test.dat可以随时更改（以root身份）。 看看它的tmpwatch（也可以在命令行中调用）的行为方式，你期望它。
另一种select可能是完全禁用tmpwatch。