Essayer de supprimer le répertoire avec "rm -rf", mais recevoir un message indiquant qu'il n'est pas vide

J'ai essayé de supprimer un répertoire en utilisant "rm -rf" et je reçois le message "Répertoire non vide":

Bens-MacBook-Pro:please benjaminhocking$ ls -lart empty_directory/
total 16
drwxr-xr-x  5 benjaminhocking  staff  170 Aug 27 14:46 .
drwxr-xr-x  3 benjaminhocking  staff  102 Aug 27 15:28 ..
Bens-MacBook-Pro:please benjaminhocking$ rm -rf empty_directory/
rm: empty_directory/: Directory not empty
Bens-MacBook-Pro:please benjaminhocking$ rmdir empty_directory/
rmdir: empty_directory/: Directory not empty

Si j'essaye la même chose en utilisant le Finder (en faisant glisser le dossier vers la Corbeille), je reçois le message

L'opération ne peut pas être terminée car l'élément «répertoire_vide» est en cours d'utilisation.

J'ai essayé de faire xattr -d com.apple.quarantine, purement par superstition, mais ça n'a pas servi.

Un élément de contexte probablement important est que ce répertoire était initialement dans un répertoire qui aurait dû être supprimé par une commande "make clean" que j'ai lancée avant que Terminal ne se bloque sur moi, après quoi un peu plus de la moitié des autres programmes que j'avais en cours d'exécution également verrouillé, y compris Skype, et éventuellement le système d'exploitation lui-même. J'ai fini par devoir redémarrer l'ordinateur en appuyant longuement sur la touche marche / arrêt.

Modifier pour ajouter: Une autre information importante que j'ai laissée est que cela se passait dans un dossier crypté à la encfs. J'ai pu retrouver le dossier correspondant dans le côté crypté des choses et le supprimer là-bas. Je ne sais toujours pas pourquoi je ne pouvais pas le faire du côté déchiffré de choses comme je le fais normalement. Je vais laisser cela sans réponse pour l'instant au cas où quelqu'un aurait une bonne réponse à cela.

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

$ rmdir -r empty_directory/

Si cela ne fonctionne pas, essayez:

$ rm -rf empty_directory/

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

$ lsof +D empty_directory/

Cela devrait indiquer si des fichiers de 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)tous les exécutables qui pourraient utiliser ce répertoire ou tout fichier caché à l'intérieur. Il est probable que le Finder utilise un fichier caché dans le empty_directoryrépertoire pour stocker les paramètres d'affichage des dossiers. J'espère que cela t'aides.

PS: Pour savoir si lsof(8)est installé, entrez:

$ lsof

Si la sortie ressemble à ceci, elle lsof(8)est installée sur votre système.

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

Recherchez les fichiers cachés et chiffrés ou les fichiers de clés de chiffrement dans ce répertoire. Ce pourrait être le coupable.

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

Si cela se produit et que vous êtes sûr de vouloir tout supprimer, essayez d'utiliser sudo rm -rf directory/

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 rechercher et de trouver ce fil. Je ne sais pas s'il peut y avoir eu des points supplémentaires involontairement non déclarés par rapport à la question d'origine, mais dans mon cas, la racine du problème, et la solution était:

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

• toute lstentative du Finder ou de la ligne de commande ne montrait rien .et et..

• Je me suis connecté au serveur de disque réseau via la sshcommande et ls -aly ai vérifié . Le résultat a montré, en plus de .et .., plusieurs .__filenameéléments avec des informations de sécurité étendues (c'est-à-dire +ajoutées au mode).

Je crois que ce sont, ou sont similaires à, les fichiers que je note d' abord il y a Mac OSX créer des années lors de l' utilisation cp -R, tarou cpioà des groupes d'archives ou déplacer des fichiers. J'avais déduit à l'époque qu'ils étaient utilisés pour réinitialiser correctement certaines propriétés de fichier après le déplacement - peut-être uid / gid, mode, acls, mtime / utime / ctime, etc; Je ne suis pas vraiment sûr - les propriétés qui n'avaient pas été réinitialisées correctement par ces commandes avant ce moment (je me souviens qu'OSX incluait des commandes mvmacet cpmaccontournaient le problème avant que ces .__filenametypes de fichiers ne commencent à 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 lecteur interne, USB ou Firewire; c'était la première fois que je les trouvais sur un disque réseau; complètement indétectable du côté client du support, mais normal à tous points de vue vu du côté serveur.

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

Donc, il y a une autre réponse pour ce que ça vaut; une autre solution potentielle à ce problème si elle devait apparaître pour n'importe qui en conjonction avec un disque réseau.

J'ai essayé toutes les réponses ici sans résultat. Cependant, j'ai pu déplacer le répertoire de côté en utilisant la commande mv , ce qui m'a permis de continuer.

La seule solution qui a fonctionné pour moi était de /unix/234876/unable-to-delete-a-file-wwhat-i-do :

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

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

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

Pour le bénéfice des lecteurs:

Attention rm -rfdans un tel cas! Cela peut créer des problèmes ailleurs s'il s'agit d'un partage réseau! Tu étais prévenu!

Dans presque tous les cas, si un directorysemble vide, utilisez rmdir directoryou peut-être sudo rmdir directory. N'utilisez pas rm(ou delsous Windows). Si cela ne fonctionne pas, vous devez savoir ce qui bloque cette demande, corriger cela, puis réessayer rmdir.

Veuillez noter que je ne connais pas OS-X, mais je pense que les choses sont très similaires au comportement Unix / BSD.

Il est très probable que le répertoire en question était juste un point de montage (à partir de l'encfs) ou résidant sur un point de montage devenu en lecture seule ou bloqué dans un état incorrect (ce qui a empêché la suppression du répertoire). Si vous forcez maintenant la suppression du répertoire, de très mauvaises choses peuvent se produire.

Dans le bon cas, le répertoire était vraiment vide, donc le supprimer (détruire la monture, etc.) ne faisait plus de mal. Dans le mauvais cas, il n'était pas vide, il semblait juste l'être, ce qui signifie que vous avez jeté quelque chose que vous ne vouliez peut-être pas tuer. Tout dépend du type de montage, des pilotes utilisés, etc. pp.

Si les choses sont mises en œuvre raisonnablement bien, normalement rien de mal ne devrait se produire. Mais ce n'est pas le cas normal. Les choses sont déjà dans un état étrange, ce qui signifie: Quelque chose ne va pas, alors mieux vaut ne pas essayer de mélanger encore plus! Si quelque chose est fissuré, tout mauvais contact pourrait le casser.

Par exemple, si vous rencontrez une condition de concurrence critique sur un partage réseau, il se peut que votre rm -rfsupprime les données qui sont juste copiées sur le partage par quelqu'un d'autre.

Cependant, il rmdirest garanti de ne jamais faire de mal, en plus de supprimer des répertoires vraiment vides. Cela est même vrai sur NFS, car NFS garantit uniquement un comportement vraiment atomique sur mkdiret rmdir, mais nulle part ailleurs.

Pour info:

Vous pouvez détecter un point de montage à l'aide de l'outil mountpoint directory. Vous pouvez également regarder la sortie de mountet essayer de repérer vos montures là-bas. Mais attention, au moins sous Linux, cela pourrait mentir. Utilisation de l' mountpointutilitaire plus fiable mais moins pratique.

Dans ce cas, vous avez trouvé le point de montage, vous pouvez le démonter puis supprimer le répertoire, voici la séquence suivante:

umount directory rmdir directory

Si nécessaire, utilisez sudo, comme d'habitude.

Remarques:

• Les partages réseau peuvent refuser rmdir(et toute autre chose) en raison des droits d'accès.

• Les systèmes de fichiers défectueux peuvent refuser rmdir, selon la stratégie d'échec. Peut-être verrez-vous un message raisonnable dans ce cas, peut-être pas.

• Sous Linux (et probablement n'importe quel système d'exploitation moderne), vous pouvez également restreindre l'accès en utilisant différents moyens (comme monter quelque chose en lecture seule, des capacités comme dans SeLinux, etc.). Cela signifie alors que vous ne voyez pas qu'il s'agit d'un point de montage et que vous ne voyez rien de mal, mais cela ne fonctionne tout simplement pas. Dans ce cas, vous devez rechercher une autre raison et cela peut être profondément enfoui dans le système d'exploitation. Cela dépend de l'outil si vous voyez un message d'erreur raisonnable. Jetez peut-être aussi un œil au syslog / kernel-log comme dmesgsous Linux (désolé, je ne connais pas l'équivalent OS-X).

• Notez que le verrouillage de fichier obligatoire peut également être une source. Bien que cela soit normal sous Windows, ce n'est généralement pas le cas normal d'Unix et je ne l'ai jamais entendu pour les répertoires. Les verrous de fichiers obligatoires sont couverts par POSIX, mais ils sont facultatifs.

• Très souvent dans de tels cas, le répertoire en question réside sur un système de fichiers différent de celui auquel vous pensiez. Vous pouvez le découvrir avec la commande df directory(je pense que c'est la même chose sous OS-X).

• Vous pouvez inspecter plus en profondeur avec des outils comme statou statfssur le répertoire. Cependant, ces niveaux sont un peu bas pour les gens normaux, et bien souvent, ces outils sont bien cachés des utilisateurs normaux.

• Les répertoires peuvent avoir des fichiers avec des noms amusants. Comme un fichier qui efface immédiatement la sortie du terminal, il semble donc qu'il ne soit pas là. Essayez quelque chose comme ls -al | lessou utilisez quelque chose comme MidnightCommander mc.

Il y a une charge de train d'autres possibilités, y compris des insectes, des haxors, des extraterrestres ou peut-être des choses plus exotiques comme les fées. Mais généralement, il n'est pas sage de commencer à chercher là-bas, essayez plutôt de trouver l'erreur à vos côtés, car "errare humanum est".

Cela pourrait également être un cas que je viens de résoudre dans lequel un lien symbolique cassé était du côté serveur et n'était pas visible pour le client via CIFS. Le lien symbolique a rempli un répertoire non vide, mais le client n'a pas pu voir ni statuer le lien symbolique dans le but de vider le répertoire avant de le dissocier. Puisqu'il était invisible, il a créé ce paradoxe où du côté client, il était vide mais "pas vide" lors d'un défi par rm . Si vous avez un accès SSH au serveur, essayez un shell à cette extrémité et voyez si le répertoire est vraiment vide ou s'il peut avoir des liens symboliques cassés. J'ai pu le faire sur un Drobo5N et cela m'a sauvé les fesses.

Essayez d'ouvrir ce répertoire à partir de Windows, il peut y avoir quelque chose qui ne s'affiche pas sous Mac OS. J'ai eu un problème similaire après un certain nombre d'opérations de copie entre Mac et Win PC: le répertoire était vide même dans le terminal mais sur Windows, j'ai trouvé un fichier Windows caché, j'ai donc réussi à supprimer le répertoire à partir de là.

Dans le terminal:

1. enter sudo su (l'invite de ligne de commande doit basculer vers quelque chose comme sh-3.2#.)
2. accédez au dossier parent de celui que vous souhaitez supprimer
3. entrer rm -rf TheDirectoryYouWantToDelete

J'ai rencontré ce problème lors de la tentative de suppression d'un dossier utilisé par une application. Lorsque j'ai fermé l'application, cela m'a permis de supprimer le dossier sans lancer cette erreur, essayez donc de quitter les applications qui pourraient l'utiliser.