Dans le répertoire racine de ma clé USB, parfois lorsque je lance ls, la sortie est normale et elle répertorie les fichiers. À d'autres moments, la sortie est simplement une ligne:
$ ls
.
Si j'essaye ls -laà l'un de ces moments, j'obtiens ceci:
$ ls -la
ls: .: Invalid argument
Si je cours lsplusieurs fois de suite, il semble renvoyer la sortie normale ou la sortie anormale essentiellement au hasard.
lssemble fonctionner normalement dans d'autres répertoires. ls $drivenamesemble même fonctionner correctement à partir du répertoire parent et ls ..semble fonctionner correctement à partir d'un répertoire enfant. (Bien que je ne puisse pas être sûr à 100% de ceux qui "fonctionnent normalement" car le comportement est indéterminé pour commencer.) J'ai essayé deux autres lecteurs USB externes et j'ai eu le même comportement.
Que se passe t-il ici? Je suis sur Mac OS X 10.11.3.
Edit: Belle idée, mais je ne semble pas utiliser d'alias, et /bin/lsdonne le même résultat.
/bin/ls?/bin/lsdonne le même résultat, parfois en sortie..lssemble fonctionner normalement dans d'autres répertoires.ls NO\ NAMEsemble même fonctionner correctement à partir du répertoire parent etls ..semble fonctionner correctement à partir d'un répertoire enfant. (Bien que je ne puisse pas être sûr à 100% de ceux qui "fonctionnent normalement" car le comportement est indéterminé pour commencer.)lsutilisez-vous?/bin/ls --versiondevrait fonctionnerRéponses:
Il peut s'agir d'un bogue dans le pilote du système de fichiers pour FAT32 sur les versions récentes d'OSX. Cela semble également se produire uniquement lorsque le répertoire de travail se trouve à la racine du lecteur monté. Si c'est dans un sous-répertoire ou n'importe où ailleurs sur le système, les choses semblent fonctionner.
Il y a une discussion intéressante dans ce fil, y compris les traces du système. https://github.com/robbyrussell/oh-my-zsh/issues/4161
la source
CONTOURNEMENT: (probablement une partie de ce que le demandeur apprécierait même s'il ne l'a pas spécifiquement demandé)
Reportez-vous au répertoire actuel de presque n'importe quelle autre manière que
.. Exemple:cddans un sous-répertoire, puis exécutezlssur le répertoire parent. Autrement dit, entrez quelque chose comme ceci:mkdir S; cd S ; /bin/ls -al ..Ou référez-vous à son nom de chemin complet. Exemple:
ls /Volumes/microSD007Pour moi, l'une de ces solutions de contournement fonctionne (c'est-à-dire qu'elles aboutissent à la sortie attendue) quand
lsme donne la même sortie erronée que l'OP a signalée. (Et pour moi, il n'y a pas de sortie dans dmesg quand illsagit bizarrement.)Je vois les mêmes dysfonctionnements sur 10.12.6 dans Terminal.app exécutant bash. Idem dans
cshetshmême après avoir défini TERM sur vt100. Cette solution de contournement fonctionne également dans ces coquilles.Et je suis d'accord qu'il y a un bogue
stat64, comme indiqué dans lezshfil de discussion que Neil nous indique. (Je pensais que le problème était dû à une mémoire flash défectueuse et / ou fausse, et je me demande toujours si c'est un facteur parfois.)J'ai remarqué que ce bug affecte également:
ls, etlslorsqu'il est utilisé en mode shell d'Emacs.la source
Si vous supprimez parfois le lecteur, la réponse est que chaque fois que vous réinsérez le lecteur, vous devez retourner dans le répertoire à l'aide de cd. En effet, le descripteur de fichier ouvert par votre shell pour lire le répertoire est invalidé lorsque le lecteur est supprimé et n'est pas réinitialisé automatiquement lorsque le lecteur est réinséré (même si vous avez peut-être utilisé le lecteur dans un autre terminal ou gestionnaire de fichiers).
Si le lecteur n'est jamais retiré, il peut s'agir d'un problème matériel ou d'un logiciel qui démonte le lecteur pour une raison quelconque; vous devez fournir les journaux système.
la source