Intentando eliminar el directorio con "rm -rf", pero recibo el mensaje de que no está vacío

Intenté eliminar un directorio usando "rm -rf" y recibo el mensaje "Directorio no vacío":

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 intento lo mismo con Finder (arrastrando la carpeta a la Papelera), recibo el mensaje

La operación no se puede completar porque el elemento "directorio_vacío" está en uso.

He intentado hacerlo por xattr -d com.apple.quarantinepura superstición, pero no sirvió de nada.

Un contexto probablemente importante es que este directorio estaba inicialmente en un directorio que debería haber sido eliminado por un comando "make clean" que emití antes de que Terminal me bloqueara, después de lo cual un poco más de la mitad de los otros programas que tenía también está bloqueado, incluido Skype, y eventualmente el sistema operativo en sí. Terminé teniendo que reiniciar la computadora presionando y sosteniendo la tecla de encendido.

Editar para agregar: Otra información importante que dejé fue que esto estaba sucediendo en una carpeta encriptada a la encfs. Pude rastrear la carpeta correspondiente en el lado cifrado de las cosas y eliminarla allí. Todavía no sé por qué no pude hacerlo desde el lado descifrado de las cosas como lo hago normalmente. Dejaré esto sin respuesta por ahora en caso de que alguien tenga una buena respuesta para eso.

Reinicie su computadora y rmdir(1)vuelva a ejecutarla .

$ rmdir -r empty_directory/

Si eso no funciona, intente:

$ rm -rf empty_directory/

Si aún no funciona, suponiendo que OS X se haya lsof(8)preinstalado, ingrese:

$ lsof +D empty_directory/

Esto debería indicar si algún archivo de este directorio está siendo utilizado por algún programa. Creo que el sistema de archivos HFS + no permite la eliminación de archivos en uso. De todos modos, killall(1)cualquier ejecutable que pueda estar usando este directorio o cualquier archivo oculto dentro de él. Es probable que Finder esté utilizando un archivo oculto en el empty_directorydirectorio para almacenar la configuración de vista de carpeta. Espero que esto ayude.

PD: para saber si lsof(8)está instalado, ingrese:

$ lsof

Si el resultado se ve así, entonces lsof(8)está instalado en su sistema.

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

Compruebe si hay archivos ocultos y cifrados o archivos de clave de cifrado en ese directorio. Estos podrían ser los culpables.

Reparar el disco usando la Utilidad de Discos solucionó este problema para mí.

Si esto sucede y está seguro de que desea eliminar todo, debe intentar usar sudo rm -rf directory/

Me encontré exactamente con este error al intentar eliminar un directorio (rm -r dirname). Ya había probado todas las sugerencias que he leído aquí antes de buscar y encontrar este hilo. No sé si es posible que haya habido puntos adicionales que no se hayan expresado involuntariamente en la pregunta original, pero en mi caso la raíz del problema y la solución fue:

• el directorio en cuestión estaba en un disco montado en red

• cualquier lsintento desde el Finder o la línea de comando no mostró más que .y..

• Ingresé al servidor de disco de red a través del sshcomando y verifiqué ls -alallí. El resultado mostró, además de .y .., varios .__filenameelementos con información de seguridad extendida (es decir, +adjuntada al modo).

Creo que estos son, o son similares a, archivos, que me observó por primera vez la creación de Mac OS X Hace años cuando se utiliza cp -R, taro cpiopara grupos de almacenamiento o mover de archivos. Había deducido en el momento que se usaron para restablecer correctamente algunas propiedades del archivo después del movimiento, tal vez uid / gid, mode, acls, mtime / utime / ctime, etc. No estoy realmente seguro: las propiedades que esos comandos no habían restablecido correctamente antes de ese momento (recuerdo que OSX solía incluir mvmacy cpmaccomandos para solucionar el problema antes de que estos .__filenametipos de archivos comenzaran a aparecer al usar las formas habituales de cp, tar, etc.)

Nunca tuve problemas para eliminar estos archivos cuando se escribieron en una unidad interna, USB o Firewire; Esta fue la primera vez que los encontré en un disco de red; completamente indetectable desde el lado del cliente del montaje, pero normal en todos los sentidos cuando se ve desde el lado del servidor.

rm -rf dirname desde un inicio de sesión en el servidor de disco de red eliminó correctamente el directorio junto con su contenido.

Entonces, hay otra respuesta para lo que vale; Otra posible solución a este problema si apareciera para cualquiera junto con un disco de red.

Intenté todas las respuestas aquí sin resultados. Sin embargo, pude mover el directorio a un lado usando el comando mv , lo que me permitió continuar.

La única solución que funcionó para mí fue /unix/234876/unable-to-delete-a-file-whatever-i-do :

Muévalos a / tmp y reinicie.

Las otras opciones que probé fueron:

• Utilidad de disco - Primeros auxilios.
• lsof +D bad_file no mostró salida.
• sudo rm -rf
• Arranque en terminal de usuario único y rm -rf.

Para beneficio de los lectores:

¡Cuidado rm -rfen tal caso! ¡Puede crear problemas en otro lugar en caso de que sea un recurso compartido de red! ¡Usted ha sido advertido!

En casi todos los casos, si a directoryparece estar vacío, use rmdir directoryo tal vez sudo rmdir directory. No lo use rm(o delbajo Windows). Si esto no funciona, debe averiguar qué bloquea esta solicitud, corregirla y luego volver a intentarlo rmdir.

Tenga en cuenta que no conozco OS-X, pero creo que las cosas allí son muy similares al comportamiento de Unix / BSD.

Es muy probable que el directorio en cuestión fuera solo un punto de montaje (desde los encfs) o que residiera en un punto de montaje que se volviera de solo lectura o se atascara en algún estado incorrecto (lo que impidió que se eliminara el directorio). Si ahora fuerza la eliminación del directorio, pueden ocurrir cosas muy malas.

En el buen caso, el directorio realmente estaba vacío, por lo que quitarlo (destruir el montaje, etc.) no causó más daño. En el mal caso, no estaba vacío, simplemente parecía estarlo, lo que significa que destrozaste algo que quizás no querías matar. Todo esto depende del tipo de montaje, qué controladores están en uso, etc. pp.

Si las cosas se implementan razonablemente bien, normalmente no debería pasar nada malo. Sin embargo, este no es el caso normal. Las cosas ya están en un estado extraño, lo que significa: algo está mal, ¡así que mejor no intentes mezclarlo aún más! Si algo está roto, cualquier toque incorrecto podría romperlo.

Por ejemplo, si alcanza una condición de carrera en un recurso compartido de red, puede ser que rm -rfelimine los datos que alguien más acaba de copiar al recurso compartido.

Sin embargo, rmdirse garantiza que nunca hará daño, además de eliminar directorios realmente vacíos. Esto es incluso cierto en NFS, porque NFS solo garantiza un comportamiento verdaderamente atómico en mkdiry rmdir, pero en ningún otro lugar.

FYI:

Puede detectar un punto de montaje con la herramienta mountpoint directory. Alternativamente, mire la salida de mounte intente detectar sus monturas allí. Pero cuidado, al menos bajo Linux esto podría mentir. Usando la mountpointutilidad más confiable pero menos conveniente.

En ese caso, encontró el punto de montaje, puede desmontarlo y luego eliminar el directorio, esta es la siguiente secuencia:

umount directory rmdir directory

Si es necesario sudo, use , como siempre.

Notas:

• Los recursos compartidos de red pueden negarse rmdir(y cualquier otra cosa) debido a los derechos de acceso.

• Los sistemas de archivos defectuosos pueden negarse rmdir, dependiendo de la estrategia de falla. Tal vez verá un mensaje razonable en ese caso, tal vez no.

• Bajo Linux (y probablemente cualquier sistema operativo moderno) también puede restringir el acceso utilizando diferentes medios (como montar algo de solo lectura, capacidades como en SeLinux, etc.). Esto significa que no ve que es un punto de montaje y que no ve nada malo, pero simplemente no funciona. En ese caso, debe buscar alguna otra razón y puede estar muy enterrado en el sistema operativo. Depende de la herramienta si ve algún mensaje de error razonable. También quizás eche un vistazo al syslog / kernel-log como dmesgen Linux (lo siento, no sé el equivalente de OS-X).

• Tenga en cuenta que el bloqueo obligatorio de archivos también puede ser una fuente. Si bien esto es normal en Windows, generalmente no es el caso normal de Unix y nunca lo escuché por directorios. Los bloqueos de archivos obligatorios están cubiertos por POSIX, pero son opcionales.

• Muy a menudo en tales casos, el directorio en cuestión reside en un sistema de archivos diferente al que pensaba. Puede averiguar cuál, con el comando df directory(creo que esto es lo mismo en OS-X).

• Puede inspeccionar más a fondo con herramientas como stato statfsen el directorio. Sin embargo, estos son un nivel un poco bajo para las personas normales, y con frecuencia estas herramientas están bien ocultas para los usuarios normales.

• Los directorios pueden tener archivos con nombres divertidos. Como un archivo que borra inmediatamente la salida del terminal, por lo que parece que no está allí. Pruebe algo como ls -al | lesso use algo como MidnightCommander mc.

Hay muchas otras posibilidades, como insectos, haxors, extraterrestres o quizás cosas más exóticas como las hadas. Pero, por lo general, no es aconsejable comenzar a buscar allí, primero trate de encontrar el error a su lado, porque "errare humanum est".

Esto también podría ser un caso que acabo de resolver en el que un enlace simbólico roto estaba en el lado del servidor y no era visible para el cliente a través de CIFS. El enlace simbólico llenó un directorio no vacío, pero el cliente no pudo ver ni establecer el enlace simbólico con el propósito de borrar el directorio antes de desvincularlo. Como era invisible, creó esta paradoja en la que, desde el lado del cliente, estaba vacía pero "no estaba vacía" ante el desafío de rm . Si tiene acceso SSH al servidor, pruebe con un shell en ese extremo y vea si el directorio está realmente vacío o si puede tener enlaces simbólicos rotos. Pude hacer esto en un Drobo5N y me salvó el trasero.

Intente abrir ese directorio desde Windows, puede haber algo que no se muestra en Mac OS. Tuve un problema similar después de varias operaciones de copia entre Mac y Win PC: el directorio estaba vacío incluso en la terminal, pero en Windows encontré un archivo de Windows oculto, así que eliminé el directorio de allí con éxito.

En la terminal:

1. enter sudo su (La línea de comando debería cambiar a algo como sh-3.2#).
2. navegue a la carpeta principal de la que desea eliminar
3. entrar rm -rf TheDirectoryYouWantToDelete

Encontré este problema al intentar eliminar una carpeta que estaba usando una aplicación. Cuando cerré la aplicación, me permitió eliminar la carpeta sin arrojar este error, así que trate de cerrar las aplicaciones que podrían estar utilizándola.