Frage Gibt es unter Linux nicht löschbare Dateien?


Ich habe das noch nie zuvor gesehen (20 Jahre * nix). Ich habe versucht, meine Festplatte zu speichern (Details auf Anfrage) und waren ziemlich erfolgreich, außer es gibt einige Dateien, die wie folgt aussehen:

$ ls -al
$ ?????????? ?    ?       ?      ? blah.txt

Diese Datei wird nicht von rm, rm -f, shred, mv, chown, chmod oder anderen Befehlen beeinflusst, die mir einfallen.

Beispiel

# whoami
root

# rm -f blah.txt
rm: cannot remove `blah.txt': permission denied

# ls -la blah.txt
?????????? ?    ?       ?      ? blah.txt

Grundsätzlich das gleiche für alle Befehle in dieser Datei.

Irgendwelche Ideen?


4
2017-12-13 07:46


Ursprung


20 Jahre Unix und du hast noch nie ein beschädigtes Dateisystem und / oder kaputtes HD gesehen? Du Glückspilz. - Janne Pikkarainen
Ah, das dachte ich mir. Ja, ich glaube, ich hatte Glück. Die HD ist nicht kaputt, übrigens. Funktioniert gut. - bev
Das bedeutet normalerweise, dass der Dateiname im Verzeichnis aufgeführt ist, aber nicht auf seinen Inode zugreifen kann. Es könnte eine fehlerhafte Inode-Nummer im Verzeichnis enthalten sein oder der Inode auf der Festplatte ist möglicherweise beschädigt. - mark4o


Antworten:


Kannst du uns die Ausgabe von 'lsattr blah.txt' zeigen? Das würde uns sagen, welche speziellen Flags diese Datei gesetzt hat.

Können Sie auch dmesg (das Kernel-Debug-Nachrichtenprotokoll) für etwas Neues einchecken (führen Sie dmesg zweimal aus, einmal vor dem Versuch, eine Datei zu entfernen, und danach, ob am Ende des Protokolls etwas Neues angezeigt wurde).

Eine Beispiel-Dateisystem-Korruptionsnachricht kann folgendermaßen aussehen:

[86777.332361] EXT4-fs (dm-0): error count: 436
[86777.332365] EXT4-fs (dm-0): initial error at 1290174395: ext4_mb_generate_buddy:726
[86777.332367] EXT4-fs (dm-0): last error at 1292151653: ext4_mb_generate_buddy:726
[86777.332419] EXT4-fs (dm-8): error count: 1406
[86777.332423] EXT4-fs (dm-8): initial error at 1290623933: ext4_mb_generate_buddy:726
[86777.332425] EXT4-fs (dm-8): last error at 1292168399: ext4_mb_generate_buddy:726

und es zeigt an, dass ~ 86777 Sekunden seit dem Booten (dieser Teil wird möglicherweise nicht auf Ihrem System angezeigt wird, es hängt von einer Kernel-Einstellung ab), es gab zwei Fehler, die das EXT4-Dateisystem auf meiner Testmaschine betreffen.


1
2017-12-13 10:42



@qdot, danke für den Tipp. Ich kann es noch nicht versuchen, weil etwas, das ich versuchte, das Problem beseitigte. Ich "berührte" die Datei (ich hatte es aufgegeben, Daten wiederherzustellen) und nun sieht die Datei einfach wie eine normale Datei ohne Inhalt aus. Während ich durch meine fs wandere, bin ich mir sicher, dass ich mehr davon sehen werde (2 bisher), an diesem Punkt versuche ich lsattr und poste das Ergebnis. - bev
@qdot - ok hier ist die Ausgabe: lsattr: Operation nicht unterstützt Beim Lesen von Flags auf blah.txt. ABER, lsattr gibt keine Informationen für irgendeine Datei auf meinem System zurück. Es heißt: lsattr: Unzulängliches ioctl für Gerät beim Lesen von Flags auf <jeder Datei>. Also funktioniert entweder lsattr nicht auf reiserfs oder meine Festplatte ist beschädigt, scheint aber gut zu funktionieren. Hmmmmm. Jetzt dmesg ansehen. - bev
ReiserFS: Warnung: is_tree_node: Knoten-Level 0 stimmt nicht mit dem erwarteten überein 1 ReiserFS: sda3: Warnung: vs-5150: search_by_key: ungültiges Format in Block 869576 gefunden. Fsck? ReiserFS: sda3: Warnung: vs-13070: reiserfs_read_locked_inode: Fehler beim Versuch, Statistikdaten von [265071 265097 0x0 SD] zu finden ReiserFS: Warnung: is_tree_node: Knotenebene 0 stimmt nicht mit der erwarteten überein 1 ReiserFS: sda3: Warnung: vs-5150: search_by_key: ungültiges Format in Block 869576 gefunden. Fsck? - bev
Yah. Sieht so aus, als ob es ein Problem mit der Inode-Struktur gibt. Ich werde wieder fsck laufen. - bev
Ran fsck - check, was mir jetzt sagt, dass eine Menge Korruption herrscht und ich fsck --rebuild-tree laufen lassen muss. Nachdem ich meine Partition vor ein paar Tagen gesichert hatte, habe ich das ausgeführt. Ich werde auf das Ergebnis zurückkommen. - bev


Dein Dateisystem ist beschädigt. Ein Fsck würde wahrscheinlich helfen.

edit: wenn Sie ReiserFS nicht verwenden, in welchem ​​Fall fsck es möglicherweise weiter beschädigt ...


7
2017-12-13 08:34



Das war das erste, was ich getan habe. Es gab keine schlechten Blöcke. - bev
Es kann nichts anderes sein. Überdenken Sie diese Möglichkeit. Allerdings habe ich gerade bemerkt, dass Sie ReiserFS verwenden. Beachten Sie, dass ReiserFS fsck Ihr Dateisystem zerstören könnte. Das ist einer von ReiserFS Designfehlern ... - jlliagre
Einer von Reiserfs Designfehlern ist, dass das Laufen von Reiserfsck ein Dateisystem zerstören könnte? Das ist gut zu wissen (nachdem ich natürlich Reiserfsck auf meinem Dateisystem lief) werde ich versuchen, eine Dokumentation dazu zu finden. Glücklicherweise habe ich vor zwei Tagen alles wieder gut gemacht. Oh - und du hattest Recht. Ich lief fsck und es zeigte mir viele Probleme. - bev
Von en.wikipedia.org/wiki/ReiserFS: Der Tree-Rebuild-Prozess von ReiserFS fsck hat viel Kritik erregt: Wenn das Dateisystem so stark beschädigt wird, dass seine interne Struktur unbrauchbar ist, kann das Durchführen einer Baumrekonstruktion weitere Dateien beschädigen oder neue Einträge mit unerwartetem Inhalt einführen - jlliagre
@jlligre - Danke für den Link. Ziemlich beängstigend. Ich denke über meinen nächsten Schritt nach. Ich habe die gesamte Partition gesichert. Ich habe Grund zu der Annahme, dass das körperliche hd in Ordnung ist, die aktuelle Situation liegt daran, dass ich mit zwei externen hds herumhänderle, nachdem ich die Sicherung gemacht habe (obwohl ich nicht sehe, was ich getan habe, was das verursacht hat). Würden Sie vorschlagen, die Partition zu shredden und mit ext3 zu formatieren? Danke für den Rat. - bev


chattr +i file macht eine Datei komplett schreibgeschützt, auch von root. Es heißt unveränderlich. Um sie zu löschen oder zu modifizieren, müssen Sie sie zunächst wieder umänderbar machen chattr -i file.


4
2017-12-13 07:50



Danke für die Hilfe, leider hat es nicht geklappt. Hier ist, was passiert ist: $> chattr -i blah.txt $> chattr: Berechtigung verweigert, während stat zu versuchen blah.txt - bev