Почему `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 если вы беспокоитесь о влиянии производительности на выполнение этого в необузданном узком цикле.)

Запустите это в сеансе screen и проверьте это позже. Когда сценарий выходит сообщает , что он обнаружил ошибку, проверьте missing.out , чтобы увидеть , какие файлы ls не удалось найти, то проверить , являются ли эти файлы перечислены в ls1.out , но не ls3.out

Не забудьте проверить ctime, сообщаемое ls , на случай, если этот загадочный процесс удалит файл, а затем воссоздать новый файл с тем же именем как раз вовремя, чтобы третий ls перечислил его. :)

Если окажется, что по какой-то причине причина не в том, что процесс удалил файл во время работы ls , сообщите здесь, и мы выясним, что еще можно попробовать.