find 命令正在选择不相关模式的文件

Question

我怀疑这是由于其他一些并行作业正在删除某些文件。

这正是本例中发生的情况。你find发现有一个文件yumn.txt，然后该文件被删除，然后find尝试对该文件执行某些操作但失败了。对于，情况也是一样的ztry.txt。

注意，这并不意味着如果yumn.txt没有同时删除，find则会删除并打印它。这仅意味着在测试完成yumn.txt之前意外消失了。find

您可能希望根据唯一的目录列表-name "qwer_*"拒绝（首先从中了解文件的存在），因此该工具永远不需要查询文件本身（稍后，当文件不存在时）。我的测试表明情况并非总是如此。yumn.txtfind

一般来说find，可以重新排列测试，也可以不重新排列测试。这意味着-name "qwer_*"可以在测试之前或之后进行测试-mtime +31等。例如，GNUfind重新排列表达式，以便尽早执行仅基于文件名的测试。请参阅man 1 find、-O和-D选项。但对于你的情况或许您首先输入的内容会首先进行测试，因此yumn.txt需要针对-type f和进行测试-mtime +31，并且这些测试中至少有一项要求文件在执行测试时存在。

但即使使用 sole 也find . -name "qwer_*"有可能遇到问题。我是这样测试的：

while true; do touch yumn.txt; rm yumn.txt; done &

然后ls yumn.txt会不会找到文件。您可以重复ls yumn.txt多次，有时会找到文件，有时找不到。这是意料之中的。

在我的 Debian 中，当yumn.txt在 Btrfs 文件系统上不断创建和销毁时，find . -name "qwer_*"并不会抱怨；或者至少在我反复测试超过 4k 次时没有抱怨。

另一方面，在我的 OpenWRT 路由器上，find . -name "qwer_*"有时做投诉，信息几乎和你的一模一样：

find: ./yumn.txt: No such file or directory

它find来自 BusyBox，文件系统是overlayfs（以ext3upperdir 为准）。结论是：在某些情况下，另一个进程删除的文件可能会发出find抱怨（并返回非零退出状态！），即使-name理论上可以首先拒绝该文件。

这不是一个通用的解决方案，但根据您的具体情况，您可以尝试这种方法：

find /home/my_home/document/qwer_* -maxdepth 0 -type f -mtime +31 -delete -print

现在 shell 执行模式匹配，并find仅以匹配的文件作为起点运行。由于-maxdepth 0 find仅检查给定的文件（如果其中至少一个恰好是目录，则相关）。这样消失yumn.txt或类似情况就不会影响find。可能的问题：

如果qwer_*文件被其他进程删除（如yumn.txtwas），则可能会发生find投诉并返回非零退出状态。
如果文件太多，qwer_*那么您将得到Argument list too long（或类似的）。
如果根本没有匹配，find将会获取文字的/home/my_home/document/qwer_*起点并抱怨不存在的文件/目录。

Answer 1

在你的上一个问题你说：