Disque externe, ne peut pas vider la corbeille, rm voit un fichier, mais pas ls -la

9

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 -rfpour le supprimer via le terminal

$ rm -rf folder/
rm: folder/: Directory not empty

Si j'utilise ls -lapour 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 *.mp3renvoie ls: 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 -ibne 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 -laje ne pouvais pas le voir, alors que rm -ic'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)

bitinn
la source
1
Avez-vous envisagé de sauvegarder tout ce que vous voulez - probablement déjà sauvegardé de toute façon ... puis de reformater complètement ce disque pour recommencer?
Solar Mike
Affiche ls -ble fichier? Si c'est le cas, vous pouvez ls -biobtenir l'inode et suivre la réponse ci-dessous, ou alternativement simplement copier le nom de fichier dans la -bsortie.
Reid
Je crois que le problème principal n'est pas avec le nom de fichier, ls -bi *.mp3affichez le même résultat que celui indiqué dans OP.
bitinn

Réponses:

10

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, cddans 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.

Doc G.
la source
Wow, c'est un bug incroyablement terrible.
chrylis -on strike-
2
Je ne pense pas que ce soit exact. Le terminal peut masquer des caractères uniques qu'il ne peut pas restituer, mais il ne supprimera pas la totalité de la ligne de texte.
duskwuff -inactive-
1
@duskwuff Quoi qu'il en soit, il semble que le nom de fichier cause des problèmes, il s'agit donc d'une solution potentielle.
JAB
Désolé mais le problème semble plus complexe que ça: j'ai essayé $ ls -i *.mp3, ça revient ls: 03 - Ēlusion.mp3: No such file or directory.
bitinn
1
Pouvez-vous simplement exécuter ls -idans le répertoire pour empêcher l'expansion du caractère générique du shell d'interférer?
nohillside
9

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 :

OS X est le plus étrange, à la fois en ce qu'il normalise les noms de fichiers et en ce qu'il utilise NFD au lieu du NFC le plus courant .

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 lsré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:

entrez la description de l'image ici

  • 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:

entrez la description de l'image ici

et ls -laibrésultat:

$ ls -laib
total 46592
2762318 drwxrwxrwx  1 user  staff    131072 Jan  3  2017 .
2685260 drwxrwxrwx  1 user  staff    131072 Jan  3  2017 ..
1572961 -rwxrwxrwx  1 user  staff  11672464 Aug 23  2014 Ēlusion.mp3
1572871 -rwxrwxrwx  1 user  staff  11672464 Aug 23  2014 test.mp3

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'ai initialement téléchargé ce fichier musical le 10.9 / 10.10 avec un Mac plus ancien, qui applique le nom de fichier NFD.
  • À un moment donné, je les déplace vers un lecteur Windows + NTFS, qui n'impose pas NFC / NFD, donc le nom de fichier NFD d'origine est conservé.
  • Maintenant, je veux déplacer ce fichier vers mon macOS 10.13 + APFS en utilisant un lecteur exFAT (exFAT prend en charge la même convention UTF-16 que NTFS).
  • L'enfer se déchaîne.

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:

  • Le nom de fichier Unicode est toujours une menace.
  • Vous avez réellement besoin d'un Windows / Linux pour résoudre ce problème (si la situation est que votre fichier se trouve sur un disque externe exFAT).
bitinn
la source
@bitlinn: Cliquez sur le deuxième lien dans mon commentaire adressé à duskwulff et essayez l'outil de normalisation unicode Apfelstrudel que vous y trouverez. Très utile pour APFS, inutile avec exFAT. Ou est-ce...?
Doc G.
1
@DocG. ce problème est un peu plus complexe que je ne le pensais au départ, mais j'ai encore mis à jour ma réponse!
bitinn
Ouais, je pensais que tu finirais par faire ça. Voir mon commentaire précédent sur Error 36et 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.
Doc G.