Warum gibt "ls" sporadisch nur "." im Stammverzeichnis eines externen Laufwerks?

Im Stammverzeichnis meines USB-Sticks lsist die Ausgabe manchmal normal und listet die Dateien auf. Zu anderen Zeiten ist die Ausgabe einfach eine Zeile:

$ ls
.

Wenn ich es einmal versuche ls -la, bekomme ich folgendes:

$ ls -la
ls: .: Invalid argument

Wenn ich lsmehrmals hintereinander laufe , scheint es entweder die normale Ausgabe oder die abnormale Ausgabe im Grunde zufällig zurückzugeben.

lsscheint in anderen Verzeichnissen normal zu funktionieren. ls $drivenamescheint sogar gut aus dem übergeordneten Verzeichnis ls ..zu funktionieren , und scheint gut aus einem untergeordneten Verzeichnis zu funktionieren. (Obwohl ich nicht 100% sicher sein kann, welche "normal funktionieren", da das Verhalten zunächst unbestimmt ist.) Ich habe zwei andere externe USB-Laufwerke ausprobiert und das gleiche Verhalten festgestellt.

Was ist hier los? Ich bin unter Mac OS X 10.11.3.

Bearbeiten: Gute Idee, aber ich scheine keinen Alias zu verwenden und /bin/lsgebe das gleiche Ergebnis.

osx ls usb-drive

— leekaiinthesky
quelle

Dieses ungewöhnliche Verhalten kann auf einen fehlerhaften Alias zurückzuführen sein. Was passiert, wenn Sie verwenden /bin/ls?

— DopeGhoti

funktioniert es gut in anderen Verzeichnissen?

— Liam

/bin/lsgibt das gleiche Ergebnis, manchmal Ausgabe .. lsscheint in anderen Verzeichnissen normal zu funktionieren. ls NO\ NAMEscheint sogar gut aus dem übergeordneten Verzeichnis ls ..zu funktionieren , und scheint gut aus einem untergeordneten Verzeichnis zu funktionieren. (Obwohl ich nicht 100% sicher sein kann, welche "normal funktionieren", da das Verhalten zunächst unbestimmt ist.)

— leekaiinthesky

Welches Dateisystem verwenden Sie in diesen Flash-Laufwerken? Vielleicht ist eine Anomalie von einem Windows-basierten Dateisystem abgeleitet

— RSFalcon7

Welche Version von verwenden lsSie? /bin/ls --versionsollte funktionieren

— RSFalcon7

Antworten:

Möglicherweise liegt ein Fehler im Dateisystemtreiber für FAT32 in neueren OSX-Versionen vor. Dies scheint auch nur dann aufzutreten, wenn sich das Arbeitsverzeichnis im Stammverzeichnis des bereitgestellten Laufwerks befindet. Wenn es sich in einem Unterverzeichnis oder irgendwo anders im System befindet, scheinen die Dinge zu funktionieren.

In diesem Thread gibt es einige interessante Diskussionen, einschließlich Systemspuren. https://github.com/robbyrussell/oh-my-zsh/issues/4161

— Neil
quelle

Umgehung: (wahrscheinlich ein Teil dessen, was der Fragesteller schätzen würde, selbst wenn er nicht speziell danach gefragt hätte)

Beziehen Sie sich auf fast jede andere Weise auf das aktuelle Verzeichnis als .. Beispiel:

cdin ein Unterverzeichnis und dann lsim übergeordneten Verzeichnis ausführen . Geben Sie also Folgendes ein:

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

Oder beziehen Sie sich auf den vollständigen Pfadnamen. Beispiel:

ls /Volumes/microSD007

Für mich funktioniert jede dieser Problemumgehungen (dh sie führen zu der erwarteten Ausgabe), wenn lsich dieselbe falsche Ausgabe erhalte, die das OP gemeldet hat. (Und für mich gibt es keine Ausgabe in dmesg, wenn es lsseltsam wirkt.)

Ich sehe die gleichen Fehlfunktionen auf 10.12.6 in Terminal.app, das bash ausführt. Gleiches in cshund shauch nach dem Setzen von TERM auf vt100. Diese Problemumgehung funktioniert auch in diesen Shells.

Und ich bin damit einverstanden, dass es einen Fehler gibt stat64, wie im zshThemen-Thread angegeben, auf den Neil uns hinweist. (Ich hatte gedacht, dass das Problem durch einen fehlerhaften und / oder gefälschten Flash-Speicher verursacht wurde, und mich immer noch gefragt, ob dies manchmal ein Faktor ist.)

Mir ist aufgefallen, dass dieser Fehler auch Folgendes betrifft:

Emacs 'dired-Modus, weil er aufruft ls, und
ls wenn es im Emacs-Shell-Modus verwendet wird.

— Matthew Elvey
quelle

Ich verstehe nicht, warum Goro die von ihnen vorgenommenen Änderungen vorgenommen hat, und es wurde keine Bearbeitungszusammenfassung bereitgestellt. Ich denke, sie haben die Antwort verschlimmert, und jetzt sehe ich, dass sie eine -1 erhalten hat. Ich habe eine Problemumgehung bereitgestellt. Wenn Sie meinen Indikator "Problemumgehung" entfernen, scheint es, als würde ich behaupten / versuchen, eine direkte Antwort zu geben. Ich glaube, ich biete mehr als einen Kommentar, aber weniger als eine Antwort. Soll das nicht gefördert werden? Ich habe einen neuen identifiziert; Wäre eine Bearbeitungszusammenfassung und ein Grund für -1 nicht angemessen? Goro entfernte auch eine kürzere, bessere Antwort, die ich hinzugefügt hatte. Ich verstehe es nicht

— Matthew Elvey

Ich bin auf dem Zaun; Im Allgemeinen müssen Antworten die Frage beantworten, nicht nur mehr Informationen liefern, sondern das Problem zu umgehen, ist wahrscheinlich Teil dessen, wonach der Fragesteller gesucht hat, auch wenn er es nicht ausdrücklich erwähnt hat. Die meisten Änderungen scheinen unnötig zu sein, und mindestens eine bringt die Formatierung definitiv durcheinander, also habe ich sie zurückgesetzt. Ich bin nicht sicher, ob der Beitrag jemals eine Abwertung hatte, aber es ist derzeit bei 2 Upvotes und 0 Downvotes

— Michael Mrozek

Wenn Sie das Laufwerk manchmal entfernen, lautet die Antwort, dass Sie jedes Mal, wenn Sie das Laufwerk erneut einlegen, mit cd in das Verzeichnis zurückkehren müssen. Dies liegt daran, dass der von Ihrer Shell zum Lesen des Verzeichnisses geöffnete Dateideskriptor beim Entfernen des Laufwerks ungültig wird und beim erneuten Einsetzen des Laufwerks nicht automatisch neu initialisiert wird (obwohl Sie das Laufwerk möglicherweise in einem anderen Terminal oder Dateimanager verwendet haben).

Wenn das Laufwerk nie entfernt wird, liegt möglicherweise ein Hardwareproblem oder eine Software vor, die das Laufwerk aus irgendeinem Grund aushängt. Sie sollten die Systemprotokolle bereitstellen.

— Gesetz29
quelle