Не позволяя tmpwatch забивать архивы, которые были "просто" распакованы в /tmp

У меня есть приложение, которое распаковывает архив в / tmp, восстанавливая модификацию извлеченных файлов и время доступа. Иногда этим файлам и приложенному архиву много лет. После извлечения файлов (иногда через несколько минут или часов) распаковывающее программное обеспечение будет выборочно использовать / изменять некоторые файлы. Как только это будет сделано, приложение удалит извлеченные файлы / дерево. Эта операция может происходить в любое время суток (например, в моменты, когда tmpwatch запускается cron).

Время от времени приложение начинает волноваться, потому что не может найти файл, который, как он знает, он недавно распаковал. Я думаю, что происходит, что tmpwatch спускается в распакованное дерево после того, как atime / mtime настроен (распаковкой или tar, который запускается приложением) в далекое прошлое, но до того, как приложение сможет получить доступ к соответствующему файлу. Так как tmpwatch по умолчанию смотрит на atime, он считает, что файл дряхлый, и удаляет его.

Возможно, распаковка может быть сделана в другом месте, или приложение может использовать соответствующие флаги, чтобы не сбрасывать метки времени в прошлое. Однако ни один из этих подходов не является жизнеспособным по разным причинам.

Я думаю, что я мог бы изменить скрипт tronwatch cron, чтобы учесть все это (и принять наиболее консервативное решение относительно удаления файлов), указав аргумент --ctime, а также --mtime (и ранее подразумеваемый - -время). Меня немного смущает термин "максимум этих времен", используемый на странице руководства tmpwatch, хотя мое первоначальное прочтение (пока я не посмотрел на источник C и не подумал иначе) заключалось в том, что он взял максимум различий (это означает, что он был более либеральным в удалении вещей). Означает ли это на самом деле "последнее из этих времен" (и, таким образом, tmpwatch оставит в покое файлы, которые были только что распакованы, так как их inode был затронут только недавно)?