"Erreur d'entrée / sortie" lors de l'accès à un répertoire

Je veux lister et supprimer le contenu d'un répertoire sur un disque dur amovible. Mais j'ai rencontré "erreur d'entrée / sortie":

$ 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

Je me demandais quel est le problème?

Comment puis-je récupérer ou supprimer le répertoire picet tout son contenu?

Mon système d'exploitation est Ubuntu 12.04, et le disque dur amovible a le système de fichiers ntfs. Les autres répertoires ne contenant pas ou à l'intérieur picdu disque dur amovible fonctionnent bien.

Ajoutée:

La dernière partie de la sortie de dmesgaprès j'ai essayé de lister le contenu du répertoire:

[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

Les erreurs d’entrée / sortie lors des tentatives d’accès au système de fichiers entraînent généralement des problèmes matériels.

Tapez dmesget vérifiez les dernières lignes de sortie. Si le disque ou la connexion à celui-ci échoue, il sera noté ici.

EDIT le montez -vous via ntfsou ntfs-3g? Si je me souviens bien, le ntfspilote existant ne disposait d' aucun support en écriture stable et a été en grande partie abandonné lorsqu'il s'est avéré ntfs-3gnettement plus stable et sécurisé.

Comme Sadhur le dit, cela est probablement dû à des problèmes de matériel de disque et la dmesgsortie est le bon endroit pour vérifier cela.

Vous pouvez effectuer une analyse de surface de votre disque à partir de Linux /sbin/badblocks /dev/sda.

Consultez la page de manuel pour des tests plus approfondis et des correctifs de base (déplacement de bloc). Ceci est tout agnostique du système de fichiers, il est donc sûr même avec un système de fichiers NTFS puisqu'il fonctionne au niveau de la 'surface du disque'.

J'ai personnellement fait en sorte que cela fonctionne tous les mois à partir de cron. Bien sûr, vous devez vérifier si vous recevez les mails cron dans votre boîte aux lettres (ce qui n’est souvent pas le cas par défaut). Ces mails finissent dans /var/mail/$USERou similaire.

J'ai créé /etc/cron.d/badblocks:

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

Votre système de fichiers est endommagé. Pour les volumes NTFS, vous devez exécuter un chkdsksystème sous Windows, mais il est presque impossible de le récupérer. Parfois, vous devrez peut-être formater le disque.

Une solution qui fonctionne pour moi consiste à rétrograder la ntfs-3gversion de 2014 à la version 2012. Cela devrait résoudre votre problème d’accès à la partition ntfs. À long terme, ce n'est pas une solution, car vous devrez éventuellement exécuter la dernière version.

Plus d'infos ici

Je voulais juste ajouter ma solution à ce fil au profit des autres - j'ai travaillé sur mon système en cas de panne d'alimentation - j'ai dû reconnecter les câbles SATA dans le mauvais ordre, car lorsque je les ai basculés, tout a fonctionné à nouveau - aucune idée pourquoi le disque de démarrage devait être sur un port SATA spécifique, de toute façon, pourrait être la solution pour quelqu'un d'autre.

Personne n’a indiqué quoi faire si les outils Linux ne fonctionnaient pas et que seul un Mac, mais pas Windows, est disponible.

Peut être corrigé sur OS X avec Paragon NTFS

Dans mon cas gparteddit d'aller trouver un PC Windows qui était introuvable. Mais il y avait un Mac, pour lequel ce logiciel est disponible. Installez la version d'évaluation, vérifiez , puis réparez - et voilà!

Je voulais juste partager mon expérience: sur FreeBSD 10.3, j’ai monté mon disque dur externe avec

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

À l'intérieur du disque dur, j'ai mkdircréé un répertoire puis déplacé des fichiers vers celui-ci, bien sûr avec la mvcommande. Enfin j'ai fait la commande suivante:

$ sudo sync

Ensuite, j'ai monté le disque dur sur une machine Linux avec le noyau 4.4.0-78-generic. Maintenant, quand je liste le contenu du disque dur, le répertoire créé sur FreeBSD, nommé Jeff, apparaît comme ci-dessous:

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

De plus, lors de la tentative de suppression du Jeffrépertoire, le message d'erreur suivant s'affiche:

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

Je ne pouvais pas me débarrasser du Jeffrépertoire sur la machine Linux, donc j'ai utilisé la machine FreeBSD et remonté le disque dur sur FreeBSD. Mais les commandes ls, cdet rmsur FreeBSD génèrent la même chose Input/output error. On dirait qu'il y a eu un bogue sur le ntfs-3gpaquet FreeBSD .

MISE À JOUR

J'ai transféré toutes mes données d'un disque dur externe sur une machine Linux. Bien entendu, le fichier corrompu Jeffn'a pas pu être déplacé en raison d'une erreur d'entrée-sortie. Ensuite, j'ai reformaté le disque dur externe avec remise à zéro du volume et vérification du secteur défectueux comme ceci:

$ sudo mkfs.ntfs /dev/sdb1

Et puis déplacé toutes les données vers le volume externe. De cette façon, j'ai perdu le fichier corrompu nommé Jeff, cependant, mon disque dur externe est vierge de toute erreur d'E / S.

J'ai annoncé que lorsque j'essayais d'accéder au disque sur lequel cette erreur se produisait, il essayait d'écrire les derniers fichiers copiés, puis la tentative d'accès échouait car l'enregistrement déjà écrit ne correspondait pas aux derniers éléments copiés. Le moyen le plus sain de récupérer un disque consiste à supprimer le ou les derniers éléments copiés dans Windows.