Perché "ls" emette sporadicamente solo "." nella directory principale di un'unità esterna?

Nella directory principale della mia chiavetta USB, a volte quando corro ls, l'output è normale ed elenca i file. Altre volte, l'output è semplicemente una riga:

$ ls
.

Se provo ls -lain una di quelle occasioni, ottengo questo:

$ ls -la
ls: .: Invalid argument

Se corro lsda una parte all'altra più volte, sembra restituire in modo casuale l'uscita normale o quella anormale.

lssembra funzionare normalmente in altre directory. ls $drivenamesembra persino funzionare bene dalla directory padre e ls ..sembra funzionare bene da una directory figlio. (Anche se non posso essere sicuro al 100% di quelli che "funzionano normalmente" poiché il comportamento è indeterminato per cominciare.) Ho provato altre due unità USB esterne e ho ottenuto lo stesso comportamento.

Cosa sta succedendo qui? Sono su Mac OS X 10.11.3.

Modifica: bella idea, ma sembra che non stia usando un alias e /bin/lsdia lo stesso risultato.

osx ls usb-drive

— leekaiinthesky
fonte

Questo comportamento insolito potrebbe essere il risultato di un alias malfunzionante. Cosa succede se lo usi /bin/ls?

— DopeGhoti

funziona bene in altre directory?

— Liam

/bin/lsdà lo stesso risultato, a volte in uscita .. lssembra funzionare normalmente in altre directory. ls NO\ NAMEsembra persino funzionare bene dalla directory padre e ls ..sembra funzionare bene da una directory figlio. (Anche se non posso essere sicuro al 100% di quelli che "funzionano normalmente" poiché il comportamento è indeterminato per cominciare.)

— leekaiinthesky

Quale file system stai usando in quelle unità flash? Forse è un'anomalia derivata da un filesystem basato su Windows

— RSFalcon7

Quale versione di lsstai usando? /bin/ls --versiondovrebbe funzionare

— RSFalcon7

Risposte:

Potrebbe essere un bug nel driver del file system per FAT32 nelle versioni recenti di OSX. Ciò sembra verificarsi anche quando la directory di lavoro si trova nella directory principale dell'unità montata. Se si trova in una sottodirectory o in qualsiasi altra parte del sistema, le cose sembrano funzionare.

C'è qualche discussione interessante in questo thread tra cui tracce di sistema. https://github.com/robbyrussell/oh-my-zsh/issues/4161

— Neil
fonte

Workaround: (probabilmente parte di ciò che l'appassionato apprezzerebbe anche se non lo avessero specificamente richiesto)

Fare riferimento alla directory corrente in qualsiasi altro modo diverso da .. Esempio:

cdin una sottodirectory, quindi eseguire lsnella directory principale. Cioè, inserisci qualcosa del genere:

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

Oppure fai riferimento ad esso con il suo percorso completo. Esempio:

ls /Volumes/microSD007

Per me, una di queste soluzioni alternative funziona (ovvero, lsgenera l' output previsto) quando mi dà lo stesso output errato riportato dall'OP. (E per me, non c'è output in dmesg quando lsagisce in modo strano.)

Sto vedendo gli stessi malfunzionamenti il 10.12.6 in Terminal.app che esegue bash. Lo stesso in cshe sh, anche dopo aver impostato TERM su vt100. Questa soluzione alternativa funziona anche in quelle shell.

E sono d'accordo che c'è un bug stat64, come indicato nella zshdiscussione del problema a cui Neil ci punta. (Avevo pensato che il problema fosse causato da memoria flash difettosa e / o falsa, e mi chiedo ancora se questo è un fattore a volte.)

Ho notato che questo errore riguarda anche:

La modalità diretta di Emacs, perché chiama ls, e
ls quando viene utilizzato nella modalità shell di Emacs.

— Matthew Elvey
fonte

Non capisco perché Goro abbia apportato le modifiche apportate e non è stato fornito alcun riepilogo delle modifiche. Penso che abbiano peggiorato la risposta, e ora vedo che ha ricevuto un -1. Ho fornito una soluzione alternativa, la rimozione del mio indicatore di "soluzione alternativa" mi fa sembrare che sto rivendicando / cercando di fornire una risposta diretta. Penso di offrire più di un commento, ma meno di una risposta. Non è quello di essere incoraggiato? Ne ho identificato uno nuovo; un sommario di modifica e un motivo per -1 non sarebbero appropriati? Goro ha anche rimosso una risposta più breve e migliore che avevo aggiunto. Non capisco

— Matthew Elvey,

Sono sul recinto; in genere le risposte devono rispondere alla domanda, non solo fornire ulteriori informazioni, ma aggirare il problema è probabilmente parte di ciò che cercava il richiedente anche se non lo menzionavano specificamente. La maggior parte delle modifiche sembrano in qualche modo superflue e almeno una di esse incasina la formattazione, quindi le ho ripristinate. Non sono sicuro che il post abbia mai avuto un downvote, ma attualmente è a 2 voti positivi e 0 voti negativi

— Michael Mrozek

Se a volte si rimuove l'unità, la risposta è che ogni volta che si reinserisce l'unità, è necessario tornare alla directory utilizzando cd. Questo perché il descrittore di file aperto dalla shell per leggere la directory viene invalidato quando l'unità viene rimossa e non viene reinizializzato automaticamente quando l'unità viene reinserita (anche se è possibile che sia stata utilizzata l'unità in un altro terminale o file manager).

Se l'unità non viene mai rimossa, potrebbe trattarsi di un problema hardware o forse del software che smonta l'unità per qualche motivo; dovresti fornire i log di sistema.

— Law29
fonte