我在使用 find 执行 cron 计划任务时遇到了一个奇怪的问题，它做了两件事：
- 第一行应删除以“read_”开头并以“.gz”结尾的每晚超过 3 天的文件。
- 第二行应删除每分钟以“.gz.md5”结尾的早于 1 分钟的文件。
1 1 * * * find <path that defiantly does not match> -type f -iname "read_*.gz" -ctime +3 -delete
*/1 * * * * find <path that defiantly does not match> -type f -iname "*.gz.md5" -cmin +1 -delete
通常情况下这运行良好，但时不时地在 01:01 我会收到 cron 的以下错误消息：
Cron <root@hostname> find <path that defiantly does not match> -type f -iname "read_*.gz" -mtime +3 -delete
find: ‘<path that defiantly does not match>/<hostname>/captured-syslog-1617836127-1617836351.gz.md5’: No such file or directory
但从我的角度来看，这是没有意义的。
答案1
事实：在 01:01，两个作业同时运行。
假设：相关文件系统不在目录条目中存储文件类型。
可能的解释
在某些时候find需要知道正在调查的文件的类型。显式-type测试可能是一个原因，但即使没有它（在某些情况下在它之前）也find需要知道该文件是否是目录。如果它是一个目录，那么find将下降到它。
我认为您的文件系统不会在目录条目中存储文件类型信息。在这种情况下，要知道文件类型find需要调用lstat（尽管并非总是如此，但可以进行一些优化，请参阅这个答案)，这要求该文件存在。
如果其他东西在find得知该文件位于某个目录之后但之前删除了该文件lstat，那么将会有No such file or directory.在你的情况下，“其他事情”是另一项工作。
如果文件系统将文件类型信息存储在目录条目中，则情况会有所不同。仅当其他作业删除该文件时才-ctime可能-cmin产生；No such file or directory但这不可能发生，因为-iname之前已经进行了测试并过滤掉了所有可能的干扰。
我实际上在使用和不使用该标志创建的文件系统find上测试了 GNU 。如果没有该标志，文件系统不会将文件类型存储在目录条目中。我安排了一种情况，其中文件由另一个进程创建和删除。这些文件是故意的ext4filetype没有匹配-iname与 一起使用find。
filetype在我对没有该标志的文件系统的测试中，find经常抱怨与我使用的No such file or directory文件不匹配的文件。-iname在测试中filetype find从未抱怨过。