"Eingabe- / Ausgabefehler" beim Zugriff auf ein Verzeichnis

Ich möchte den Inhalt eines Verzeichnisses auf einer Wechselfestplatte auflisten und entfernen. Aber ich habe "Input / Output-Fehler" erlebt:

$ 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

Ich habe mich gefragt, wo das Problem liegt.

Wie kann ich das Verzeichnis picund den gesamten Inhalt wiederherstellen oder entfernen ?

Mein Betriebssystem ist Ubuntu 12.04 und die Wechselfestplatte hat das Dateisystem ntfs. Andere Verzeichnisse, die picdie Wechselfestplatte nicht enthalten oder sich darin befinden, funktionieren einwandfrei.

Hinzugefügt:

Letzter Teil der Ausgabe von, dmesgnachdem ich versucht habe, den Inhalt des Verzeichnisses aufzulisten:

[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

Eingabe- / Ausgabefehler während Dateisystemzugriffsversuchen bedeuten im Allgemeinen Hardwareprobleme.

Geben dmesgSie die letzten Ausgabezeilen ein und überprüfen Sie sie. Wenn die Disc oder die Verbindung dazu fehlschlägt, wird dies dort vermerkt.

BEARBEITEN Mounten Sie es über ntfsoder ntfs-3g? Wie ich mich erinnere, hatte der Legacy- ntfsTreiber keine stabile Schreibunterstützung und wurde größtenteils aufgegeben, als sich herausstellte, dass er ntfs-3gwesentlich stabiler und sicherer war.

Wie Sadhur feststellt, liegt dies wahrscheinlich an Problemen mit der Festplattenhardware, und die dmesgAusgabe ist der richtige Ort, um dies zu überprüfen.

Sie können einen Oberflächenscan Ihrer Festplatte unter Linux durchführen /sbin/badblocks /dev/sda.

Auf der Handbuchseite finden Sie ausführlichere Tests und grundlegende Korrekturen (Blockverschiebung). Dies ist alles dateisystemunabhängig, so dass es auch mit einem NTFS-Dateisystem sicher ist, da es auf der Ebene der 'Plattenoberfläche' betrieben wird.

Ich persönlich habe dafür gesorgt, dass dies monatlich von cron ausgeführt wird. Natürlich müssen Sie überprüfen, ob Sie die Cron-Mails in Ihrer Mailbox erhalten (was in der Regel nicht der Fall ist). Diese Mails landen in /var/mail/$USERoder ähnlich.

Ich habe erstellt /etc/cron.d/badblocks:

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

Ihr Dateisystem ist beschädigt. Für NTFS-Volumes sollten Sie ein chkdskWindows-System verwenden, eine Wiederherstellung ist jedoch nahezu unmöglich. Manchmal müssen Sie möglicherweise die Festplatte formatieren.

Eine Lösung, die für mich funktioniert, ist das Downgrade der ntfs-3gVersion von 2014 auf 2012. Dies sollte Ihr Problem mit dem Zugriff auf die ntfs-Partition lösen. Auf lange Sicht ist dies keine Lösung, da Sie schließlich die neueste Version ausführen müssen.

Mehr Infos hier

Ich wollte nur meine Lösung zu diesem Thread hinzufügen, zum Wohle anderer. Ich habe an meinem System gearbeitet, als mein Netzteil ausfiel. Ich musste die SATA-Kabel in der falschen Reihenfolge wieder angeschlossen haben, als ich sie umschaltete. Alles funktionierte wieder - Keine Ahnung, warum sich die Bootdiskette auf jeden Fall an einem bestimmten SATA-Port befinden musste, könnte die Antwort für jemand anderen sein.

Niemand hat erwähnt, was zu tun ist, wenn Linux-Tools nicht funktionieren und nur ein Mac, aber kein Windows verfügbar ist.

Kann unter OS X mit Paragon NTFS behoben werden

In meinem Fall gpartedsoll ein Windows-PC gesucht werden, der nirgends zu finden war. Aber es gab einen Mac, für den diese großartige Software erhältlich ist. Installierte die Testversion, führte eine Überprüfung durch und reparierte sie - und voilà!

Ich wollte nur meine Erfahrungen teilen: Auf FreeBSD 10.3 habe ich meine externe Festplatte mit gemountet

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

Innerhalb der Festplatte habe ich mkdirein Verzeichnis erstellt und dann einige Dateien dorthin verschoben, natürlich mit mvBefehl. Schließlich habe ich den folgenden Befehl ausgeführt:

$ sudo sync

Dann habe ich die Festplatte auf einem Linux-Rechner mit Kernel 4.4.0-78-generic gemountet. Wenn ich nun den Inhalt der Festplatte aufliste, wird das unter FreeBSD erstellte Verzeichnis mit dem Namen Jeffwie folgt angezeigt:

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

Außerdem wird beim Versuch, das JeffVerzeichnis zu entfernen , die folgende Fehlermeldung angezeigt:

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

Ich konnte das JeffVerzeichnis auf dem Linux-Rechner nicht entfernen , deshalb habe ich den FreeBSD-Rechner verwendet und die Festplatte erneut auf FreeBSD gemountet. Aber die Befehle ls, cdund rmunter FreeBSD erzeugen dasselbe Input/output error. Sieht so aus, als wäre ein Fehler im FreeBSD- ntfs-3gPaket aufgetreten .

AKTUALISIEREN

Ich habe alle meine Daten von der externen Festplatte auf einen Linux-Computer Jeffverschoben. Die beschädigte Datei konnte natürlich aufgrund eines E / A-Fehlers nicht verschoben werden. Dann habe ich die externe Festplatte neu formatiert und dabei sowohl das Volume auf Null gesetzt als auch den fehlerhaften Sektor folgendermaßen überprüft:

$ sudo mkfs.ntfs /dev/sdb1

Und dann alle Daten zurück auf das externe Volume verschoben. Auf diese Weise habe ich die beschädigte Datei mit dem Namen verloren. Auf Jeffmeiner externen Festplatte ist jedoch kein E / A-Fehler aufgetreten.

Ich gab bekannt, dass beim Versuch, auf den Datenträger zuzugreifen, auf dem dieser Fehler auftritt, versucht wurde, die zuletzt kopierten Dateien zu schreiben. Dann schlägt der Zugriffsversuch fehl, da der bereits geschriebene Datensatz nicht mit den zuletzt kopierten Elementen übereinstimmt, sodass er fehlschlägt. Der gesündeste Weg, die Festplatte zu retten, besteht darin, das letzte oder die letzten in Windows kopierten Elemente zu entfernen.