Por que o 'ls' sem nenhum argumento (somente flags) me fornece “nenhum tal arquivo ou diretório”?

Question

Quando eu passo --color=always para ls, ocasionalmente gera um número de erros No such file or directory , assim:

~/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
...

Mais tarde, siga o conteúdo do diretório, incluindo o subdiretório adda_output_f89 colorido como um diretório.

Existe um processo em execução que está operando em arquivos nesse diretório, mas não acho que esteja fazendo nada com os diretórios que ls está mencionando.

Não é totalmente reproduzível. Até agora não consegui descobrir um padrão quando isso acontece e quando isso não acontece. Parece acontecer em ondas. Talvez um processo esteja rapidamente criando e removendo diretórios, mas não acho que isso seja verdade.

Parece estar acontecendo apenas quando eu passo --color=always , mas não tenho 100% de certeza de que esse é o caso. Normalmente eu uso um alias, ls='ls --classify --color=always --human-readable' onde isso acontece, mas quando eu chamo /bin/ls parece que isso não acontece.

Editar :

ls -i fornece esses arquivos:

? adda_output1_f243/  ? adda_output_f243/

etc.

Editar :

Este é um sistema de arquivos nfs.

O que pode causar esse comportamento? É algum tipo de condição de corrida?

    

Answer 1

Como mencionado nos comentários, ls em uma montagem NFS resultará em duas chamadas NFS separadas, com um pequeno atraso entre elas. Se você suspeitar que algum processo possa estar adicionando e removendo entradas no diretório, eu definitivamente o procuraria como uma explicação. Aqui está como eu testaria essa teoria.

Se o problema ocorrer um número significativo de vezes que você executar ls (ou seja, seria fácil reproduzir manualmente executando ls várias vezes), você poderia simplesmente:

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

Execute novamente esse comando até obter o erro, em seguida, inspecione o arquivo ls.out , localize os arquivos sobre os quais ele estava reclamando e veja se esses arquivos 1) existem no primeiro 1/3 da saída e 2) não existem no último 1/3 da saída. Como os arquivos foram (presumivelmente) excluídos enquanto um dos comandos ls estava sendo executado, não seria muito difícil descobrir se eles estavam lá antes e depois foram removidos.

Se a reprodução consumir muito tempo, você pode escrever um roteiro no estilo (não testado!):

#!/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

(Adicione sleep s se você estiver preocupado com o impacto no desempenho de executar isso em um loop estreito desenfreado.)

Execute isso em uma sessão screen e verifique isso depois. Quando o script sair do relatório informando que ele encontrou o erro, verifique missing.out para ver quais arquivos ls não encontraram e, em seguida, verifique se esses arquivos estão listados em ls1.out , mas não em ls3.out .

Não se esqueça de verificar a hora informada por ls , caso esse processo misterioso exclua o arquivo e recrie um novo arquivo com o mesmo nome a tempo para o terceiro ls listá-lo. :)

Se, por algum motivo, a causa não for que o processo excluiu o arquivo enquanto ls estava em execução, denuncie aqui e descobriremos o que mais tentar .