"Error de entrada / salida" al acceder a un directorio

Quiero enumerar y eliminar el contenido de un directorio en un disco duro extraíble. Pero he experimentado un "error de entrada / salida":

$ rm  pic -R
rm: cannot remove `pic/60.jpg': Input/output error
rm: cannot remove `pic/006.jpg': Input/output error
rm: cannot remove `pic/008.jpg': Input/output error
rm: cannot remove `pic/011.jpg': Input/output error

$ ls -la pic
ls: cannot access pic/60.jpg: Input/output error
-????????? ? ?    ?         ?            ? 006.jpg
-????????? ? ?    ?         ?            ? 006.jpg
-????????? ? ?    ?         ?            ? 011.jpg

Me preguntaba cuál es el problema?

¿Cómo puedo recuperar o eliminar el directorio picy todo su contenido?

Mi sistema operativo es Ubuntu 12.04, y el disco duro extraíble tiene un sistema de archivos ntfs. Otros directorios que no contienen o están dentro picdel disco duro extraíble están funcionando bien.

Adicional:

Última parte de la salida de dmesgdespués de que intenté enumerar el contenido del directorio:

[19000.712070] usb 1-1: new high-speed USB device number 2 using ehci_hcd
[19000.853167] usb-storage 1-1:1.0: Quirks match for vid 05e3 pid 0702: 520
[19000.853195] scsi5 : usb-storage 1-1:1.0
[19001.856687] scsi 5:0:0:0: Direct-Access     ST316002 1A               0811 PQ: 0 ANSI: 0
[19001.858821] sd 5:0:0:0: Attached scsi generic sg2 type 0
[19001.861733] sd 5:0:0:0: [sdb] 312581808 512-byte logical blocks: (160 GB/149 GiB)
[19001.862969] sd 5:0:0:0: [sdb] Test WP failed, assume Write Enabled
[19001.865223] sd 5:0:0:0: [sdb] Cache data unavailable
[19001.865232] sd 5:0:0:0: [sdb] Assuming drive cache: write through
[19001.867597] sd 5:0:0:0: [sdb] Test WP failed, assume Write Enabled
[19001.869214] sd 5:0:0:0: [sdb] Cache data unavailable
[19001.869218] sd 5:0:0:0: [sdb] Assuming drive cache: write through
[19001.891946]  sdb: sdb1
[19001.894713] sd 5:0:0:0: [sdb] Test WP failed, assume Write Enabled
[19001.895950] sd 5:0:0:0: [sdb] Cache data unavailable
[19001.895953] sd 5:0:0:0: [sdb] Assuming drive cache: write through
[19001.895958] sd 5:0:0:0: [sdb] Attached SCSI disk
[19113.024123] usb 2-1: new high-speed USB device number 3 using ehci_hcd
[19113.218157] scsi6 : usb-storage 2-1:1.0
[19114.232249] scsi 6:0:0:0: Direct-Access     USB 2.0  Storage Device   0100 PQ: 0 ANSI: 0 CCS
[19114.233992] sd 6:0:0:0: Attached scsi generic sg3 type 0
[19114.242547] sd 6:0:0:0: [sdc] 312581808 512-byte logical blocks: (160 GB/149 GiB)
[19114.243144] sd 6:0:0:0: [sdc] Write Protect is off
[19114.243154] sd 6:0:0:0: [sdc] Mode Sense: 08 00 00 00
[19114.243770] sd 6:0:0:0: [sdc] No Caching mode page present
[19114.243778] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[19114.252797] sd 6:0:0:0: [sdc] No Caching mode page present
[19114.252807] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[19114.280407]  sdc: sdc1 < sdc5 >
[19114.289774] sd 6:0:0:0: [sdc] No Caching mode page present
[19114.289779] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[19114.289783] sd 6:0:0:0: [sdc] Attached SCSI disk

Los errores de entrada / salida durante los intentos de acceso al sistema de archivos generalmente significan problemas de hardware.

Escriba dmesgy verifique las últimas líneas de salida. Si el disco o la conexión están fallando, se notará allí.

EDITAR ¿Lo estás montando a través de ntfso ntfs-3g? Como recuerdo, el ntfscontrolador heredado no tenía soporte de escritura estable y se abandonó en gran medida cuando resultó que ntfs-3gera significativamente más estable y seguro.

Como dice Sadhur, esto probablemente se deba a problemas de hardware del disco y la dmesgsalida es el lugar adecuado para verificar esto.

Puede emitir un escaneo de superficie de su disco desde Linux /sbin/badblocks /dev/sda.

Consulte la página del manual para ver pruebas más exhaustivas y soluciones básicas (reubicación de bloques). Todo esto es independiente del sistema de archivos, por lo que es seguro incluso con un sistema de archivos NTFS ya que funciona en el nivel de "superficie del disco".

Personalmente hice que esto se ejecutara mensualmente desde cron. Por supuesto, debe verificar si recibe los correos cron en su buzón (que a menudo no es el caso por defecto). Estos correos terminan en /var/mail/$USERo similar.

Yo creé /etc/cron.d/badblocks:

30 4 * * 3 root [ -x /sbin/badblocks ] && [ $(date +\%d) -le 7 ] && /sbin/badblocks /dev/sda

Su sistema de archivos está dañado, para volúmenes NTFS debe ejecutar un chkdsksistema bajo Windows, pero es casi imposible de recuperar. A veces puede que necesite formatear el disco.

Una solución que funciona para mí es degradar la ntfs-3gversión de la versión 2014 a la versión 2012. Esto debería resolver su problema de acceso a la partición NTFS. A la larga, esto no es una solución porque eventualmente necesitará ejecutar la última versión.

Más información aquí.

Solo quería agregar mi solución a este hilo para el beneficio de los demás. Trabajé un poco en mi sistema cuando falló mi fuente de alimentación. Debo haber vuelto a conectar los cables SATA en el orden incorrecto, ya que cuando los cambié, todo volvió a funcionar - No tengo idea de por qué el disco de arranque necesitaba estar en un puerto SATA específico, de todos modos, podría ser la respuesta para otra persona.

Nadie mencionó qué hacer si las herramientas de Linux no funcionan y solo una Mac, pero no Windows, está disponible.

Se puede arreglar en OS X con Paragon NTFS

En mi caso, gparteddijo ir a buscar una PC con Windows que no se encontraba en ninguna parte. Pero existía una Mac, para la cual está disponible este gran software. Instalado la versión de prueba, realizado verificar , a continuación, reparar - y listo!

Solo quería compartir mi experiencia: en FreeBSD 10.3, monté mi disco duro externo con

$ sudo ntfs-3g /dev/da0s1 /media

Dentro del disco duro, hice un mkdirpara crear un directorio y luego moví algunos archivos a él, por supuesto, con el mvcomando. Finalmente hice el siguiente comando:

$ sudo sync

Luego monté el disco duro en una máquina Linux con kernel 4.4.0-78-generic. Ahora, cuando enumero el contenido del disco duro, el directorio creado en FreeBSD, llamado Jeff, se muestra a continuación:

$ ls -lhrtci
ls: cannot access 'Jeff': Input/output error
total 20K
  ? d????????? ? ?    ?       ?            ? Jeff

Además, cuando intento eliminar el Jeffdirectorio, recibo el siguiente mensaje de error:

$ sudo rm -f -R Jeff
rm: cannot remove 'Jeff': Input/output error

No pude deshacerme del Jeffdirectorio en la máquina Linux, por lo tanto, usé la máquina FreeBSD y volví a montar el disco duro en FreeBSD nuevamente. Pero los comandos ls, cdy rmen FreeBSD generan lo mismo Input/output error. Parece que ha habido un error en el ntfs-3gpaquete de FreeBSD .

ACTUALIZAR

Moví todos mis datos del disco duro externo a una máquina Linux, por supuesto, el archivo dañado Jeffno se pudo mover debido a un error de E / S. Luego volví a formatear el disco duro externo con la puesta a cero del volumen y la comprobación del sector defectuoso de esta manera:

$ sudo mkfs.ntfs /dev/sdb1

Y luego movió todos los datos nuevamente al volumen externo. De esta manera, perdí el archivo dañado llamado Jeff, sin embargo, mi disco duro externo está libre de cualquier error de E / S.

Solté que cuando intento acceder al disco que produce este error, trató de escribir los últimos archivos copiados que se sobrescribieron en el último archivo y luego el intento de acceso falla porque el registro ya escrito no coincide con los últimos elementos copiados, por lo que falla. La forma más saludable de rescatar el disco es eliminar el último elemento o elementos copiados en Windows.