¿Cómo eliminar este directorio indeleble?

Desmarqué un archivo tar corrupto y logré terminar con un directorio que no puedo eliminar. Si trato de eliminarlo, parece que no se puede encontrar, pero lsmuestra que está presente, tanto con bash como con python. comportamiento similar, excepto justo después de que trato de eliminarlo rm -rf, se lsqueja de que no puede encontrarlo, luego lo enumera (ver más abajo después rm -rf). El findcomando muestra que el archivo está presente, pero aún no se me ocurre una forma de eliminarlo.
Aquí están mis intentos:

Aquí ves ambos lsy findaceptas que tenemos un directorio,

rl]$ ls
mikeaâ??cnt
rl]$ find -maxdepth 1 -type d -empty -print0  
./mikeaâcnt 

Pero no puedo eliminarlo:

rl]$ find -maxdepth 1 -type d -empty -print0 |  xargs -0 rm -f -v 
rm: cannot remove `./mikeaâ\302\201\302\204cnt': Is a directory
rl]$ ls
mikeaâ??cnt

Sin cdembargo, puedo hacerlo y está vacío:

rl]$ cd mikeaâ^Á^Äcnt/
mikeaâ^Á^Äcnt]$ ls
mikeaâ^Á^Äcnt]$ pwd
.../rl/mikeaâcnt


mikeaâ^Á^Äcnt]$ cd ../
rl]$ ls
mikeaâ??cnt

vea a continuación que no es un archivo simple sino un directorio, además se lscomporta de manera divertida después de rm -rf que dice que no puede encontrar el archivo y luego lo enumera inmediatamente después:

rl]$ rm mikeaâ^Á^Äcnt/
rm: cannot remove `mikeaâ\302\201\302\204cnt/': Is a directory
rl]$ rm -rf  mikeaâ^Á^Äcnt/
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$ 

Entonces este es el intento con python, se encuentra el archivo, pero el nombre no se puede usar como un nombre que se puede eliminar:

rl]$ python 
Python 2.6.6 (r266:84292, Jul 10 2013, 22:48:45) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import shutil
>>> os.listdir('.')
['mikea\xc3\xa2\xc2\x81\xc2\x84cnt']
>>> shutil.rmtree(os.listdir('.')[0] )
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.6/shutil.py", line 204, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/usr/lib64/python2.6/shutil.py", line 202, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: 'mikea\xc3\xa2\xc2\x81\xc2\x84cnt'

incluso cuando uso la finalización de pestañas, el nombre que recoge no se puede usar:

rl]$ rm -rf mikeaâ^Á^Äcnt 
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

usando el nombre que Python muestra con bash obtengo esto:

rl]$ rm -rf "mikea\xc3\xa2\xc2\x81\xc2\x84cnt"
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

¿Hay algo que pueda hacer para deshacerme de este directorio corrupto? El sistema de archivos subyacente (NFS) parece funcional y no se informan otros problemas, y no he tenido tales problemas hasta el archivo tar corrupto.

EDITAR: Aquí está usando findla propia -execopción para llamarrm

rl]$ find -maxdepth 1 -type d -empty -exec rm -f {} \;
find: `./mikeaâ\302\201\302\204cnt': No such file or directory
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$

pero el archivo todavía está allí (se lsqueja de que no puede encontrarlo, pero luego lo muestra de todos modos)

2da EDICIÓN:

rl]$ find -maxdepth 1 -type d -empty -exec rm -rf {} \;
find: `./mikeaâ\302\201\302\204cnt': No such file or directory
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

El comportamiento sigue sin cambios, el archivo sigue presente

3a EDICIÓN:

rl]$ ls
mikeaâ??cnt
rl]$ find -maxdepth 1 -type d -empty -exec rm -rf {} + 
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

Parece que hay más en el nombre que mikeaâcntmirar la salida del intento de Python mikea\xc3\xa2\xc2\x81\xc2\x84cnt, y esta captura de pantalla:

4th EDIT: este es el intento con un comodín:

rl]$ echo * 
mikeaâcnt
rl]$ echo mike* 
mikeaâcnt
rl]$ rm -rf mike*
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

y mi localidad:

rl]$  locale
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=

5ta Edición:

rl]$ ls -i 
ls: cannot access mikeaâcnt: No such file or directory
? mikeaâ??cnt

pero también el comportamiento ha cambiado, ahora lsy cd haz esto:

rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$ cd mikeaâ^Á^Äcnt 
mikeaâcnt: No such file or directory.

Esto ha sucedido después de los intentos de eliminación, estoy pensando que podrían ser problemas de NFS como se sugiere en una de las respuestas aquí por vinc17.

6ª EDICIÓN: Esta es la salida lsofyls -a

rl] $ / usr / sbin / lsof mikeaâ ^ Á ^ Äcnt lsof: error de estado en mikeaâ \ xc2 \ x81 \ xc2 \ x84cnt: No existe tal archivo o directorio

arriba está mal, aquí está la lsofinvocación correcta : (rl es el directorio padre)

rl]$ /usr/sbin/lsof | grep mike | grep rl 
tcsh      11926   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
lsof      14733   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
grep      14734   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
grep      14735   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
lsof      14736   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
rl]$ 

rl]$ ls -a
ls: cannot access mikeaâcnt: No such file or directory
.  ..  mikeaâ??cnt

7ª Edición: movimiento no va a funcionar, (I probado antes de todo esto, pero no lo hice guardar la salida), pero tiene el mismo problema que lsy rm con el archivo.

8ª EDICIÓN: esto está usando los caracteres hexadecimales como se sugiere:

 rl]$ ls --show-control-chars | xxd
0000000: 6d69 6b65 61c3 a2c2 81c2 8463 6e74 0a    mikea......cnt.
rl]$ rmdir $'mikea\6d69\6b65\61c3\a2c2\81c2\8463\6e74\0acnt' 
rmdir: failed to remove `mikea\006d69\006b651c3\a2c2\\81c2\\8463\006e74': No such file or directory
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$

Novena edición: para el statcomando:

 rl]$ stat  mikeaâ^Á^Äcnt 
stat: cannot stat `mikeaâ\302\201\302\204cnt': No such file or directory
 rl]$

Parece aún más probable de todos los resultados, hay un error u otro mal comportamiento de NFS como se sugiere en los comentarios.

Edición 10: Esta es una salida extraña en una esencia ya que es tan grande, es la salida o estos dos comandos:

strace -xx rmdir ./* | grep -e '-1 E'`
strace -xx -e trace=file ls -li`

https://gist.github.com/mikeatm/e07fa600747a4285e460

Edición 11: Entonces, antes de lo anterior rmdir, noté que podía cdingresar al directorio, pero después de rmdireso no pude cdnuevamente, similar a ayer. Los archivos .y ..estaban presentes:

rl]$ ls
mikeaâ??cnt
rl]$ cd mikeaâ^Á^Äcnt/
mikeaâ^Á^Äcnt]$ ls
mikeaâ^Á^Äcnt]$ ls  -a
.  ..
mikeaâ^Á^Äcnt]$ cd ../

Edición final: vi a un administrador local sobre esto y se solucionó iniciando sesión en el servidor y eliminando desde allí. La explicación de ellos es que podría ser un problema que los conjuntos de caracteres en el nombre sean inapropiados.

El siguiente extracto de este ensayo explica potencialmente por qué ese directorio se niega a ser eliminado:

NFSv4 requiere que todos los nombres de archivo se intercambien utilizando UTF-8 a través del cable. La especificación NFSv4, RFC 3530, dice que los nombres de archivo deben estar codificados en UTF-8 en la sección 1.4.3: "En una ligera desviación, los nombres de archivo y directorio están codificados con UTF-8 para tratar los conceptos básicos de la internacionalización". El mismo texto también se encuentra en la nueva sección NFS 4.1 RFC (RFC 5661) 1.7.3. El cliente actual de Linux NFS simplemente pasa los nombres de archivo directamente, sin ninguna conversión de la configuración regional actual hacia y desde UTF-8. El uso de nombres de archivo que no sean UTF-8 podría ser un problema real en un sistema que usa un sistema NFSv4 remoto; se supone que cualquier servidor NFS que siga la especificación NFS rechazará nombres de archivos que no sean UTF-8. Por lo tanto, si desea asegurarse de que sus archivos se puedan almacenar realmente desde un cliente Linux a un servidor NFS, actualmente debe usar nombres de archivo UTF-8. En otras palabras,

UTF-8 es un enfoque a más largo plazo. Los sistemas deben admitir UTF-8, así como las codificaciones más antiguas, lo que les da tiempo a las personas para cambiar a UTF-8. Para utilizar "UTF-8 en todas partes", todas las herramientas deben actualizarse para admitir UTF-8. Hace años, este era un gran problema, pero a partir de 2011 se trata esencialmente de un problema resuelto, y creo que la trayectoria es muy clara para esos pocos sistemas finales.

No todas las secuencias de bytes son legales UTF-8, y no desea tener que descubrir cómo mostrarlas. Si el núcleo aplica estas restricciones, asegurando que solo se permitan los nombres de archivo UTF-8, entonces no hay problema ... todos los nombres de archivo serán legales UTF-8. La función utf8_check C de Markus Kuhn puede determinar rápidamente si una secuencia es válida UTF-8.

El sistema de archivos debería exigir que los nombres de archivo cumplan con algún estándar, no debido a alguna necesidad malvada de controlar a las personas, sino simplemente para que los nombres siempre se puedan mostrar correctamente en un momento posterior. La falta de estándares hace las cosas más difíciles para los usuarios, no más fáciles. Sin embargo, el sistema de archivos no obliga a los nombres de archivo a ser UTF-8, por lo que puede tener basura fácilmente.

Una forma de eliminar archivos / directorios como este es mediante su referencia de inodo.

Para encontrar los inodes para elementos en el directorio actual:

ls -i
14813568 mikeaâcnt

Para borrar esto:

find . -inum 14813568 -delete

No debe usar caracteres que no sean ASCII en la línea de comando ya que, como puede ver, por alguna razón, no necesariamente se corresponden con el nombre del archivo (Unicode tiene varias formas de expresar letras acentuadas). Algo como:

rm -rf mike*

debería funcionar ya que el nombre de archivo es generado directamente por el shell. Pero asegúrese de que solo haya una coincidencia (haga una echo mike*primera para confirmar).

Bueno, si cdfunciona, entonces no hay razón por la cual rm, o lsdebería decir No such file or directory, por lo que el problema puede estar en el nivel del sistema de archivos.

Nota: No utilice lspara buscar si un directorio está vacío, pero ls -a.

El directorio aún puede ser utilizado por otro proceso (incluso si es el cwd de algún proceso). En mi humilde opinión, es por eso que todavía "existe" pero puede producir errores, por ejemplo, con ls; lsofpuede darle alguna información, pero con NFS, necesita encontrar qué máquina la usa. Especialmente con NFS, esto puede producir errores extraños. ls -aen el directorio principal podría mostrarle .nfs*archivos / directorios en algunos casos.

Cuando tengas:

$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

Sospecho que el archivo todavía existe en la tabla de directorio debido al almacenamiento en caché de NFS y / o porque es utilizado por otro proceso, pero sin la información asociada. Cuando lsintenta obtener información sobre el archivo en sí, recibe un error ya que el archivo en sí ya no existe (solo está en la tabla del directorio), de ahí el error que se muestra. Luego lsgenera el nombre del archivo porque está en la tabla de directorio. El hecho de que tenga signos de interrogación en un caso, pero no en el otro, se debe a un error de visualización en lsmi humilde opinión (no relacionado con su problema).

He probado personalmente usando findla -execdirectiva de:

$ mkdir -p mikeaâcnt
$ ls
mikeaâcnt
$ find -maxdepth 1 -type d -empty -exec rm -rf {} +
$ ls
$ 

La carpeta se creó y eliminó correctamente.

Como señaló @Igeorget , hay un método aún más simple si tienes GNU find:

$ find -maxdepth 1 -type d -empty -delete

También probé este comando y funciona correctamente

He tenido el mismo problema, creo. He visto el problema anteriormente con un nombre de archivo de ☃. lsen este caso mostraba el archivo como â??, pero pude eliminarlo con rm ☃.

Esto me llevó a la siguiente forma de convertir el nombre incorrecto al correcto:

Primero obtenga los bytes del nombre de archivo:

$ ls --show-control-chars | xxd
0000000: 6d69 6b65 61c3 a2c2 81c2 8463 6e74 0a    mikea......cnt.

Luego decodifique estos bytes como UTF-8, para obtener los puntos de código unicode, utilizando la entrada hexadecimal de este sitio web, por ejemplo: http://software.hixie.ch/utilities/cgi/unicode-decoder/utf8-decoder

U+006D LATIN SMALL LETTER M character
U+0069 LATIN SMALL LETTER I character
U+006B LATIN SMALL LETTER K character
U+0065 LATIN SMALL LETTER E character
U+0061 LATIN SMALL LETTER A character
U+00E2 LATIN SMALL LETTER A WITH CIRCUMFLEX character (â)
U+0081 <control> character (&#x0081;)
U+0084 <control> character (&#x0084;)
U+0063 LATIN SMALL LETTER C character
U+006E LATIN SMALL LETTER N character
U+0074 LATIN SMALL LETTER T character

Observe que todos estos están debajo del límite de bytes. Obtenemos los siguientes bytes:

6D 69 6B 65 61 E2 81 84 63 6E 74

Si tratamos esta secuencia en UTF-8 obtenemos:

U+006D LATIN SMALL LETTER M character
U+0069 LATIN SMALL LETTER I character
U+006B LATIN SMALL LETTER K character
U+0065 LATIN SMALL LETTER E character
U+0061 LATIN SMALL LETTER A character
U+2044 FRACTION SLASH character (⁄)
U+0063 LATIN SMALL LETTER C character
U+006E LATIN SMALL LETTER N character
U+0074 LATIN SMALL LETTER T character

Y, por lo tanto, su nombre de archivo es:, mikea⁄cntcon una barra diagonal en lugar de una normal hacia adelante. Ahora puede pasar este nombre a rmdir.

Después de obtener el código hexadecimal correcto del nombre de archivo / carpeta (usando el método que uno considere apropiado, puedo elegir ls --show-control-chars | xxd), se debe usar una construcción especial para abordar dichos caracteres cuando se ejecuta bajo bash:

rmdir $'mikea\xc3\xa2\xc2\x81\xc2\x84cnt'

De lo contrario, las barras invertidas se tratan como barras invertidas de vainilla.

¿Has intentado usar rm -rf ./mikeaâcnto rm -rf "./mikeaâcnt"o una ruta absoluta? También en lugar de rmintentarlo rmdir ./mikeaâcnt.

¿Has intentado obtener el inodo de ese archivo con stat:

stat mike*

Eso debería darle el número de inodo (y otros datos), y luego podría intentar eliminarlo.

Tuve problemas similares. ¿Tienes Gnome, KDE o algún tipo de Xwindow DM ?. Si abre el archivo broser y elimina el archivo de allí.

Deberia de funcionar.

Me gustaría ver una solución desde la línea de comandos, pero en mi caso y después de perder mucho tiempo tratando de descubrir cómo eliminarla de la línea de comando, descubrí que era tan simple como eliminar cualquier otro archivo de nautilus o cualquier otro explorador de archivos (la verdad es que solo lo he intentado con nautilus).