Por que “ls” esporadicamente produz apenas “.” no diretório raiz de uma unidade externa?

10

No diretório raiz da minha unidade flash USB, às vezes, quando executo ls , a saída é normal e lista os arquivos. Em outras ocasiões, a saída é simplesmente uma linha:

$ ls
.

Se eu tentar ls -la em um desses momentos, recebo isso:

$ ls -la
ls: .: Invalid argument

Se eu executar ls de volta para trás várias vezes, parece retornar a saída normal ou a saída anormal basicamente aleatoriamente.

ls parece funcionar normalmente em outros diretórios. ls $drivename parece funcionar bem no diretório pai, e ls .. parece funcionar bem em um diretório filho. (Embora eu não possa ter 100% de certeza dos que "funcionam normalmente", já que o comportamento é indeterminado para começar.) Eu tentei dois outros drives USB externos e tive o mesmo comportamento.

O que está acontecendo aqui? Estou no Mac OS X 10.11.3.

Editar: Boa ideia, mas parece que não estou a utilizar um alias e /bin/ls dá o mesmo resultado.

    
por leekaiinthesky 03.03.2016 / 04:46

3 respostas

6

Pode ser um bug no driver do sistema de arquivos para o FAT32 em versões recentes do OSX. Isso também parece ocorrer apenas quando o diretório de trabalho está na raiz da unidade montada. Se estiver em um subdiretório ou em qualquer outro lugar do sistema, as coisas parecem funcionar.

Existe alguma discussão interessante neste tópico, incluindo rastreios do sistema. link

    
por 28.08.2016 / 02:57
2

SOLUÇÃO ALTERNATIVA: (provavelmente parte do que o solicitante apreciaria mesmo que não pedisse especificamente)

Consulte o diretório atual em praticamente qualquer outra forma que não seja . . Exemplo:

cd para um subdiretório e, em seguida, execute ls no diretório pai. Isto é, insira algo assim:

mkdir S; cd S ; /bin/ls -al ..

Ou refira-se ao nome do caminho completo. Exemplo:

ls /Volumes/microSD007

Para mim, qualquer uma dessas soluções alternativas funciona (ou seja, elas resultam na saída esperada) quando ls me fornece a mesma saída errada relatada pelo OP. (E para mim, não há saída no dmesg quando ls age de maneira estranha.)

Estou vendo os mesmos problemas no 10.12.6 no Terminal.app executando o bash. Mesmo em csh e sh , mesmo depois de configurar TERM em vt100. Esta solução alternativa também funciona nesses shells.

Eu concordo que há um bug em stat64 , conforme indicado no tópico zsh issue que Neil nos aponta. (Eu pensava que o problema era causado por memória flash falsa e / ou falsa, e ainda me pergunto se isso é um fator às vezes.)

Percebi que esse bug também afeta:

  • modo dired do Emacs, porque chama ls e
  • ls quando é usado no modo shell do Emacs.
por 25.09.2018 / 00:21
0

Se, às vezes, você remover a unidade, a resposta é que, cada vez que você reinserir a unidade, você deverá retornar ao diretório usando cd. Isso ocorre porque o descritor de arquivo aberto pelo seu shell para ler o diretório é invalidado quando a unidade é removida e não é reinicializado automaticamente quando a unidade é reinserida (mesmo que você tenha usado a unidade em outro terminal ou gerenciador de arquivos). / p>

Se a unidade nunca for removida, pode ser um problema de hardware ou talvez algum software que desmonta a unidade por algum motivo; você deve fornecer os registros do sistema.

    
por 16.03.2016 / 07:17