J'essaie de supprimer un répertoire avec "rm -rf", mais j'obtiens un message indiquant qu'il n'est pas vide.

Redémarrez votre ordinateur et exécutez rmdir(1) encore.

$ rmdir -r empty_directory/

Si ça ne marche pas, alors essayez :

$ rm -rf empty_directory/

Si cela ne fonctionne toujours pas, en supposant que OS X a lsof(8) préinstallé, puis entrez :

$ lsof +D empty_directory/

Cela devrait indiquer si des fichiers dans ce répertoire sont utilisés par des programmes. Je pense que le système de fichiers HFS+ ne permet pas la suppression des fichiers en cours d'utilisation. Quoi qu'il en soit, killall(1) tout exécutable qui pourrait utiliser ce répertoire ou tout fichier caché à l'intérieur. Il est probable que le Finder utilise un fichier caché dans le répertoire empty_directory pour stocker les paramètres d'affichage des dossiers. J'espère que cela vous aidera.

P.S. : Pour savoir si lsof(8) est installé, entrez :

$ lsof

Si le résultat ressemble à ceci, alors lsof(8) est installé sur votre système.

lsof: /usr/bin/lsof /usr/bin/X11/lsof /usr/share/man/man8/lsof.8.gz

Vérifiez s'il y a des fichiers cachés et cryptés ou des fichiers de clé de cryptage dans ce répertoire. Ils peuvent être la cause du problème.

La réparation du disque à l'aide de l'utilitaire de disque a réglé ce problème pour moi.

La seule solution qui a fonctionné pour moi était de https://unix.stackexchange.com/questions/234876/unable-to-delete-a-file-whatever-i-do :

Déplacez-les dans /tmp et redémarrez.

Les autres options que j'ai essayées sont :

• Utilitaire de disque - Premiers secours.
• lsof +D bad_file n'a montré aucune sortie.
• sudo rm -rf
• Démarrage en terminal mono-utilisateur et rm -rf .

J'ai rencontré exactement cette erreur en essayant également de supprimer un répertoire (rm -r dirname). J'avais déjà essayé toutes les suggestions que j'ai lues ici avant de chercher et de trouver ce fil de discussion. Je ne sais pas s'il y a eu d'autres points non mentionnés dans la question initiale, mais dans mon cas, la source du problème et la solution étaient les suivantes :

• le répertoire en question se trouvait sur un disque monté en réseau

• tout ls La tentative à partir du Finder ou de la ligne de commande ne montre rien d'autre que . et ..

• Je me suis connecté au serveur de disques du réseau via le ssh et vérifié ls -al là. Le résultat a montré, en plus de . et .. , plusieurs .__filename les éléments avec des informations de sécurité étendues (c'est-à-dire, + ajouté au mode).

Je pense qu'il s'agit de fichiers, ou qu'ils sont similaires, que j'ai remarqué pour la première fois sous Mac OSX il y a quelques années en utilisant cp -R , tar ou cpio pour archiver ou déplacer des groupes de fichiers. J'avais déduit à l'époque qu'ils étaient utilisés pour réinitialiser correctement certaines propriétés des fichiers après le déplacement - peut-être uid/gid, mode, acls, mtime/utime/ctime, etc. no étaient correctement réinitialisées par ces commandes avant cette période (je me souviens qu'OSX incluait habituellement mvmac et cpmac pour contourner le problème avant que ces .__filename types de fichiers ont commencé à apparaître lors de l'utilisation des formes habituelles de cp , tar etc).

Je n'avais jamais rencontré de problème pour supprimer ces fichiers lorsqu'ils avaient été écrits sur un disque interne, USB ou Firewire ; c'était la première fois que je les trouvais sur un disque réseau ; complètement indétectables du côté client du montage, mais normaux en tous points lorsqu'ils étaient vus du côté serveur.

rm -rf dirname à partir d'un login sur le serveur de disque réseau a correctement supprimé le répertoire ainsi que son contenu.

Il y a donc une autre réponse qui vaut ce qu'elle vaut, une autre solution potentielle à ce problème s'il devait apparaître pour quiconque en conjonction avec un disque réseau.

J'ai essayé toutes les réponses ici, sans résultat. J'ai cependant réussi à déplacer le répertoire à part en utilisant la fonction mv qui m'a permis de continuer.