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

Question

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'essaie la même chose en utilisant le Finder (en faisant glisser le dossier dans la corbeille), je reçois le message

L’opération ne peut pas être terminée car l’élément "empty_directory" est utilisé.

J'ai essayé de faire xattr -d com.Apple.quarantine, purement hors de la 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 émise avant le verrouillage du terminal 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 redémarrer l'ordinateur en maintenant la touche marche/arrêt enfoncée.

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

Jonathan Reno · Answer

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

$ rmdir -r empty_directory/

Si cela ne fonctionne pas, alors essayez:

$ rm -rf empty_directory/

Si cela ne fonctionne toujours pas, en présumant que lsof(8) est préinstallé sur OS X, 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 de fichiers en cours d'utilisation. Quoi qu'il en soit, killall(1) tous les exécutables susceptibles d'utiliser ce répertoire ou les fichiers cachés qu'il contient. 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 t'aides.

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

$ lsof

Si la sortie 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

Recherchez les fichiers cachés et chiffrés ou les fichiers de clé de chiffrement dans ce répertoire. Ceux-ci pourraient être le coupable.

Shlok Datye · Answer

Réparer le disque en utilisant Utilitaire de disque a résolu ce problème pour moi.

Ken · Answer

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'avais lues ici avant de chercher et de trouver ce fil. Je ne sais pas s'il y a peut-être eu des points supplémentaires laissés sans le vouloir de façon non explicite par rapport à la question initiale, mais dans mon cas, la source du problème, et la solution était:

le répertoire en question était sur un disque monté sur le réseau
toute tentative de ls à partir du Finder ou de la ligne de commande n'a montré que . et ..
Je me suis connecté au serveur de disque réseau via la commande ssh et j'ai coché ls -al. Le résultat a montré, en plus de . et .., plusieurs éléments .__filename avec des informations de sécurité étendues (c'est-à-dire, + ajouté au mode).

Je pense que ce sont, ou sont similaires, des fichiers que je remarquais pour la première fois sous Mac OSX en créant 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 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 cette date (je me souviens qu'OSX incluait les commandes mvmac et cpmac pour contourner le problème Avant que ces .__filename types de fichiers ne commencent à apparaître avec les formes habituelles de cp, tar, etc.).

Je n'avais jamais eu 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 de la monture, mais normal à tous égards 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 avec son contenu.

Donc, il y a une autre réponse pour ce que ça vaut; Une autre solution potentielle à ce problème s’il doit apparaître pour toute personne associée à un disque réseau.

m1. · Answer

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

Jeremy Ninnes · Answer

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

Joe · Answer

La seule solution qui a fonctionné pour moi a été de https://unix.stackexchange.com/questions/234876/unable-to-delete-a-file-wther-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.

Tino · Answer

Pour le bénéfice des lecteurs:

Attention rm -rf dans un tel cas! Cela peut créer des problèmes ailleurs, au cas où il s'agirait d'un partage de réseau! Vous avez été prévenu!

Dans presque tous les cas, si directory semble être vide, utilisez rmdir directory ou peut-être Sudo rmdir directory. N'utilisez pas rm (ou del sous Windows). Si cela ne fonctionne pas, vous devez savoir ce qui bloque cette demande, y remédier, puis réessayer rmdir.

Veuillez noter que je ne connais pas OS-X, mais je pense que les choses là-bas sont très semblables 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ésidait sur un point de montage devenu en lecture seule ou bloqué dans certains état incorrect (ce qui a empêché le répertoire d'être supprimé). Si vous forcez maintenant la suppression du répertoire, de très mauvaises choses peuvent arriver.

Dans le bon cas, le répertoire était vraiment vide, donc le supprimer (détruire le montage, etc.) ne faisait plus de mal. Dans le mauvais cas, ce n'était pas vide, cela semblait juste être, ce qui signifie que vous avez détruit 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 correctement mises en œuvre, normalement rien ne devrait se passer. Cependant, ce n'est pas le cas normal. Les choses sont déjà dans un état bizarre, ce qui signifie: Quelque chose ne va pas, alors mieux vaut ne pas essayer de le mélanger encore plus loin! Si quelque chose est fissuré, un mauvais contact peut le casser.

Par exemple, si vous rencontrez une situation critique sur un partage réseau, il se peut que votre rm -rf supprime les données qui sont simplement copiées sur le partage par quelqu'un d'autre.

Cependant, il est garanti que rmdir ne fera jamais de mal, en plus de supprimer les répertoires vraiment vides. Ceci est même vrai sur NFS, car NFS ne garantit que le comportement réellement atomique sur mkdir et rmdir, mais nulle part ailleurs.

FYI:

Vous pouvez détecter un point de montage à l'aide de l'outil mountpoint directory. Vous pouvez également examiner la sortie de mount et essayer d’y repérer vos montures. Mais méfiez-vous, au moins sous Linux, cela pourrait mentir. L'utilisation de l'utilitaire mountpoint est 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. La séquence est la 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 de droits d'accès.
Les systèmes de fichiers défectueux peuvent refuser rmdir, selon la stratégie d'échec. Vous verrez peut-être un message raisonnable dans ce cas, peut-être pas.
Sous Linux (et probablement tout système d’exploitation moderne), vous pouvez également restreindre l’accès de différentes manières (telles que le montage en lecture seule, des fonctionnalités telles que SeLinux, etc.). Cela signifie alors que vous ne voyez pas que c'est un point de montage et que vous ne voyez rien d'anormal, mais cela ne fonctionne tout simplement pas. Dans ce cas, vous devez rechercher une autre raison et il peut être très profondément enfoui dans le système d'exploitation. Cela dépend de l'outil si vous voyez un message d'erreur raisonnable. Consultez également le fichier syslog/kernel-log comme dmesg sous Linux (désolé, je ne connais pas l’équivalent d’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 Unix et je ne l'ai jamais entendu parler de répertoires. Les verrous de fichiers obligatoires sont couverts par POSIX, mais ils sont facultatifs.
Assez souvent dans de tels cas, le répertoire en question réside sur un système de fichiers différent de celui que vous pensiez. Vous pouvez savoir lequel, 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 tels que stat ou statfs sur le répertoire. Cependant, ils sont un peu bas pour les gens normaux, et très souvent, de tels 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 | less ou utilisez quelque chose comme MidnightCommander mc.

Il existe une foule d'autres possibilités, y compris des insectes, des haxors, des extraterrestres ou peut-être des choses plus exotiques comme des fées. Mais en général, il n’est pas sage de commencer par regarder là-bas, mais essayez d’abord de trouver l’erreur de votre côté, car "errare humanum est".

Jon · Answer

Cela pourrait également être un cas que je viens de résoudre dans lequel un lien symbolique brisé se trouvait côté serveur et n'était pas visible par le client via CIFS. Le lien symbolique a rempli un répertoire non vide, mais le client n'a pas été en mesure de voir ou de déclarer le lien symbolique dans le but de vider le répertoire avant de le dissocier. Comme il était invisible, il a créé ce paradoxe dans lequel, côté client, il était vide mais "pas vide" lors d’une contestation de rm . Si vous avez un accès SSH au serveur, essayez un shell à cette fin et voyez si le répertoire est vraiment vide ou s'il contient des liens symboliques rompus. J'ai été capable de faire cela sur un Drobo5N et cela m'a sauvé les fesses.

contre_force · Answer

Essayez d'ouvrir ce répertoire à partir de Windows, il peut y avoir quelque chose qui ne s'affiche pas sous Mac OS. J'avais 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 sous Windows, j'ai trouvé un fichier Windows masqué. J'ai donc supprimé le répertoire avec succès.