J'effaçais un dossier de musique dans mon lecteur externe et j'ai trouvé un répertoire que je ne peux pas supprimer, peu importe ce que j'essaie.
Si je le mets dans la corbeille via l'interface graphique
L'opération ne peut pas être terminée car l'élément «dossier» est en cours d'utilisation.
Si j'utilise rm -rf
pour le supprimer via le terminal
$ rm -rf folder/
rm: folder/: Directory not empty
Si j'utilise ls -la
pour vérifier son contenu
$ ls -la
total 512
drwxrwxrwx 1 user staff 131072 Jan 3 2017 .
drwxrwxrwx 1 user staff 131072 Jan 3 2017 ..
Si j'utilise rm -i *
dans le dossier
$ rm -i *
rm: 03 - Ēlusion.mp3: No such file or directory
Si j'utilise sudo lsof +D folder/
pour vérifier si des fichiers sont ouverts
Rien ne revient à la sortie du programme.
Si j'utilise l'Utilitaire de disque pour réparer le disque et le volume (premiers secours)
Bilan de santé réussi donc aucune réparation n'a été lancée
Si je redémarre macOS
Le problème persiste.
Information additionnelle:
Je peux déplacer le dossier dans le lecteur, mais pas vers un autre lecteur.
Je peux renommer le dossier.
ls -i *.mp3
renvoiels: 03 - Ēlusion.mp3: No such file or directory
, identique àrm -i *.mp3
.Le fichier n'apparaît pas dans le Finder, c'est une partie déroutante, quel que soit le problème d'affichage du nom de fichier que Terminal pourrait avoir (je le configure toujours pour l'utiliser
Unicode - UTF-8
), je pense qu'il y a plus de force en jeu.
En réponse aux questions, non, ls -ib
ne retourne rien.
$ ls -i
$ ls -ib
$ ls -laib
total 512
2762318 drwxrwxrwx 1 user staff 131072 Jan 3 2017 .
2685260 drwxrwxrwx 1 user staff 131072 Jan 3 2017 ..
Donc, apparemment, il y a quelque chose mais ls -la
je ne pouvais pas le voir, alors que rm -i
c'est bizarre avec le nom de fichier?
get info
via le menu contextuel de l'interface graphique a confirmé qu'il y a 1 élément dans le dossier, mais avec zéro octet, et n'apparaît certainement pas dans le Finder.
Je ne sais pas quoi faire à ce stade. Aide très appréciée!
(Utilisation de 10.13.4 + ExFAT sur un disque externe)
la source
ls -b
le fichier? Si c'est le cas, vous pouvezls -bi
obtenir l'inode et suivre la réponse ci-dessous, ou alternativement simplement copier le nom de fichier dans la-b
sortie.ls -bi *.mp3
affichez le même résultat que celui indiqué dans OP.Réponses:
Le problème semble provenir d'un fichier nommé 03 - usionlusion.mp3 situé dans le répertoire nommé dossier .
Parce que Terminal.app n'est pas en mesure de restituer les signes diacritiques dans les noms de fichiers - c'est vrai, mais c'est au-delà de la portée de fournir la solution la plus simple pour vous - il cache son échec en masquant le nom de fichier (quelque chose que je n'avais jamais entendu auparavant) ; peut-être les changements de High Sierra dans /.file, /.volfs et les inodes 64 bits? Attendez - tant pis; votre modification de votre question me dit que je vous ai mal compris.) Quoi qu'il en soit, l'existence du fichier est connue, avec l'ironie affirmation du Finder selon laquelle il n'existe pas. De toute évidence, c'est le cas. Voici comment changer cela:
Tout d'abord, déterminez le numéro d'inode du fichier. Dans Terminal.app,
cd
dans le répertoire "dossier" et exécutez cette commande:ls -i *.mp3
Copiez la chaîne numérique de l'inode fournie dans la colonne de gauche de la réponse, qui sera quelque chose comme
12345678 03 - E ̄lusion.mp3
--et placez-le dans cette commande, qui le renommera en quelque chose que le terminal peut rendre correctement:
find . -inum 12345678 -exec mv {} deletemenow \;
- vous donnant le fichier "deletemenow" dans le dossier "folder", tous deux dont vous pouvez disposer de la manière qui vous convient le mieux.
la source
$ ls -i *.mp3
, ça revientls: 03 - Ēlusion.mp3: No such file or directory
.ls -i
dans le répertoire pour empêcher l'expansion du caractère générique du shell d'interférer?Il m'a fallu beaucoup de temps pour arriver à ce résumé, mais je pense que c'est la réponse définitive.
La cause de mon problème est bien connue :
Historiquement (pas si ancien, avant la période 10.11), OS X + HFS + applique le formulaire NFD sur tous les noms de fichiers , et vous n'obtiendrez le résultat NFD que par les commandes et les appels système.
Ensuite, les choses commencent à changer, en 10.11, certains résultats des appels système sont normalisés en NFC , ce qui le met en ligne avec Windows et Linux, mais au détriment de certains programmes qui attendent NFD sur OS X.
Mais depuis l'introduction de macOS 10.13 + AFPS, le comportement change à nouveau: Apple décide qu'il veut se normaliser en NFD lors de l'affichage et des appels système , mais laisse les noms de fichiers d'origine tels quels (donc NFC et NFD sont pris en charge, mais si vous sélectionnez le nom de fichier dans le Finder ou copier le
ls
résultat dans Terminal, vous obtenez le formulaire NFD).Tout cela est génial, jusqu'à ce que vous mettiez un fichier avec le nom de fichier NFD dans un lecteur externe en utilisant exFAT (car c'est le seul format cross-macOS / Windows avec une prise en charge de la taille de fichier de 4 Go +): macOS 10.13 pense que votre fichier doit être au format NFC, donc il a mis le bug.
En fait, voici un test rapide, j'ai un dossier sous Windows sur mon lecteur exFAT avec 3 fichiers:
test.mp3
Ēlusion.mp3
(Ē
en NFC)03 - Ēlusion
(Ē
en NFD)(Vous pouvez copier l'unicode exact ici )
Lorsque je les monte sur mon macOS, voici ce que je vois:
et
ls -laib
résultat:Comme vous pouvez le voir, le fichier NFC est présent mais le fichier NFD est manquant.
Même si vous êtes conscient du problème NFC / NFD sur OS X , vous ne pouvez pas vous attendre à ce que le lecteur externe exFAT affronte ce problème de la manière opposée (NFC est bien, mais NFD est pant-on-fire).
Mais qu'est-ce qui aurait pu amener mon fichier musical à utiliser le nom de fichier NFD en premier lieu:
J'aurais pu copier le fichier via un lecteur en réseau ou TeamViewer, et ce serait bien, mais exFAT déclenche ce bogue sur macOS.
Cours:
la source
Error 36
et faire une recherche sur le Web pour quelque chose comme "déplacer les fichiers en avant et en arrière sur l'erreur mac 36 de Windows" pour plus d'informations sur la séparation des attributions de fichiers sur les systèmes non HFS. Il s'agit d'un (autre) problème connu de dénomination des fichiers MacOS / OS X depuis l'arrivée du système 10.6. Entre la normalisation Unicode et la séparation des attributs dot_underscore, vous avez rencontré un sacré double bug. Je doute que la commande dot_clean ait une chance.