为什么没有任何参数（只有标志）的`ls` 给我“没有这样的文件或目录”？

Question

当我传递--color=always给 ls 时，它偶尔会输出一些No such file or directory错误，如下所示：

~/svn/projects/submm/adda/scat$ /bin/ls --color=always
ls: cannot access adda_output_f89: No such file or directory
ls: cannot access adda_output_f150: No such file or directory
ls: cannot access adda_output_f183: No such file or directory
ls: cannot access adda_output_f186: No such file or directory
ls: cannot access adda_output_f190: No such file or directory
...

稍后跟随目录的内容，包括adda_output_f89着色为目录的子目录。

有一个正在运行的进程正在对该目录中的文件进行操作，但我认为它没有对ls提到的目录执行任何操作。

它不能完全重现。到目前为止，我还没有成功地找出什么时候发生和什么时候不发生的模式。它似乎发生在波浪中。也许一个过程正在快速创建和删除目录，但我认为这不是真的。

它似乎只有在我通过时才会发生--color=always，但我不能 100% 确定情况确实如此。通常我会使用别名，ls='ls --classify --color=always --human-readable'在它确实发生的地方，但是当我调用/bin/ls它时，它似乎没有发生。

编辑：

ls -i 为这些文件提供：

? adda_output1_f243/  ? adda_output_f243/

等等。

编辑：

这是一个 nfs 文件系统。

什么可能导致这种行为？这是某种竞赛条件吗？

Answer 1

正如评论中提到的，ls在 NFS 挂载中将导致两个单独的 NFS 调用，它们之间有轻微的延迟。如果您怀疑某些进程可能会在目录中添加和删除条目，我肯定会对此进行解释。以下是我检验该理论的方法。

如果您运行多次时出现问题（即，通过手动运行多次ls很容易重现），您可以简单地：ls

{ ls;ls;ls; } 2>&1 | tee ls.out | grep 'No such file'

重新运行该命令，直到出现错误，然后检查该ls.out文件，找到它所抱怨的文件，然后查看这些文件是否 1) 存在于输出的前 1/3 中，2) 不存在于输出中输出的最后 1/3。由于这些文件（大概）是在其中一个ls命令运行时被删除的，因此应该不难弄清楚它们是否之前存在并在之后删除。

如果复制非常耗时，您可以编写一个脚本（未经测试！）：

#!/bin/bash

while /bin/true; do
  /bin/ls -lc >ls1.out 2>&1
  /bin/ls -lc >ls2.out 2>&1
  /bin/ls -lc >ls3.out 2>&1
  grep 'No such file' ls2.out >missing.out 2>&1
  if (( $? != 0 )); then
    echo "Found the error!"
    break
  fi
done

（sleep如果您担心在无限制的紧密循环中运行它会对性能产生影响，请添加 s。）

在会话中运行它screen并稍后检查。当脚本退出并报告发现错误时，请missing.out检查哪些文件ls找不到，然后验证这些文件是否列在ls1.out但未在ls3.out.

不要忘记验证 报告的 ctime ls，以防这个神秘进程碰巧删除了该文件，然后在第三个进程中及时重新创建一个同名的新文件ls列出它。:)

如果事实证明，由于某种原因，原因不是进程在运行时删除了文件ls，请在此处报告，我们将找出还可以尝试的其他方法。