Dateien auf Korrektheit prüfen auf HD

  • Was heißt das? Da werden doch hoffentlich nicht die Dateien manipuliert, die man vor Manipulation schützen will, und eine Prüfsumme angehängt?

    Edit: In der Beschreibung steht: "Diese tackert es standardmäßig als Attribut an die Datei." Aber wie geht das, kenne ich bislang nicht?

    Linux-Dateisysteme wie Ext4, BTRFs unterstützen erweiterte Dateiattribute (extended file attributes). Darin speichert checkit die Checksumme. Der Inhalt, die Daten der Datei bleiben dabei unberührt. Finde ich eine clevere Idee.

    Allerdings macht das Projekt keinen besonders vertrauenswürdigen Eindruck auf mich. Lizenz ist GPLv3, aber ich finde kein git-Repo für die Sourcen. Es gibt nur einen Link zu einem Source-Tar-File einer früheren Version (0.5.2). Deb-Pakete gibt es nur bis Debian 11. In den Standard-Repos von Debian und Fedora ist checkit trotz seiner OpenSource-Lizenz nicht enthalten.

    Zotac ZBox ID91: Zorin OS 18 (GNOME) und GuideOS 1.0
    Geekom Mini IT11: Fedora 44 Silverblue (GNOME)
    Macbook Pro 2015: Fedora 43 Workstation (GNOME)

  • Es gibt da ein Tool Namens "Czkawka", gibt es auch in der Anwendungsverwaltung als Flatpak, hier lassen sich Dateien usw. vergleichen und auch explizit nach defekten Dateien suchen, allerdings nur PDF, Ton, Archiv und Bild Dateien, evtl. hilft das ja schon mal. :)

  • Es gibt da ein Tool Namens "Czkawka", gibt es auch in der Anwendungsverwaltung als Flatpak, hier lassen sich Dateien usw. vergleichen und auch explizit nach defekten Dateien suchen, allerdings nur PDF, Ton, Archiv und Bild Dateien, evtl. hilft das ja schon mal. :)

    Hab mir mal mehrere Beschreibungen durchgelesen. Dort heißt es "findet doppelte Dateien". Für sowas nutze ich dupeGuru. Ich suche mal nach dem Windows-Tool.

  • Checkit kann im nachhinein auch keine Fehler erkennen, wenn vorher keine Checksumme erstellt wurde.

    Es erstellt auch erstmal eine Checksumme und kann erst dann prüfen ob Änderungen vorliegen.

  • Ich möchte nur darauf Hinweisen, dass sich seit Jahrzehnten ganz andere Leute über diese Grundproblematik Gedanken machen. Aus diesem Grunde gibt es zfs und xfs. Und wenn man Vertrauen dazu hat, auch btrfs. Das ist die Sache mit den Checksums.

    So sieht ein xfs_repair Ablauf bei einer gesunden Partition mit 600GB aus:

    pc ~ # xfs_repair /dev/sdb9
    Phase 1 - Superblock finden und überprüfen...
    Phase 2 - ein internes Protokoll benutzen
           - Null-Protokoll...
           - freier Speicher und Inode-Karten des Dateisystems werden
    gescannt...
           - Wurzel-Inode-Stück gefunden
    Phase 3 - für jedes AG...
           - agi unverknüpfte Listen werden gescannt und bereinigt...
           - bekannte Inodes werden behandelt und Inode-Entdeckung wird
    durchgeführt...
           - agno = 0
           - agno = 1
           - agno = 2
           - agno = 3
           - neu entdeckte Inodes werden behandelt...
    Phase 4 - auf doppelte Blöcke überprüfen...
           - Liste mit doppeltem Ausmaß wird eingerichtet...
           - es wird geprüft ob Inodes Blocks doppelt beanspruchen...
           - agno = 0
           - agno = 2
           - agno = 1
           - agno = 3
    Phase 5 - AG-Köpfe und Bäume werden erneut gebildet...
           - Superblock wird zurückgesetzt...
    Phase 6 - Inode-Verbindbarkeit wird geprüft...
           - Inhalte der Echtzeit-Bitmaps und Zusammenfassungs-Inodes werden zurückgesetzt
           - Dateisystem wird durchquert ...
           - durchqueren beendet ...
           - nicht verbundene Inodes werden nach lost+found verschoben ...
    Phase 7 - Verweisanzahl wird geprüft und berichtigt...
    erledigt

    (dauerte rund 30sec)

    Ist sie "krank", sieht das nicht viel anders aus, kann aber deutlich länger dauern, 2x oder 3x. Zum Beispiel bei nicht ordentlichem runterfahren. Letztens gabs technische Unterbrechungen, mit Ausfall-Meldungen, weil die Maschine überfordert war, kurz vor Batterie-Ende. Eine externe Festplatte. Swappen bis der Arzt kommt. Da dachte ich, jetzt habe ich nach Jahren doch mal wieder Datenverlust. War aber nicht! Er konnte alles wieder finden und das Dateisystem in Ordnung bringen. Xfs-Format, heute im professionellem Einsatz bei Redhat, und auch dort gepflegt, ursprünglich von Firma SGI in die Welt gesetzt. Seit 2001 im Kernel, 2020 überarbeitet (Version 5). Von mir seit der Zeit auch auf allen Last-tragenden Datenpartitionen genutzt. Hat sogar den Vorteil, dass es im Verhältnis zu ext4 mehr Speicherplatz bei gleicher Plattengröße bietet, was sich bei großen Partitionen deutlich bemerkbar macht.

    Das ersetzt natürlich nicht die Überprüfung alter Medien. Nur: wenn alte Medien kein wie-auch-immer-geartetes Schlüsselsystem haben, nützt das nichts. Wenn es nur lesbare Texte sind, gibt's die visuelle Überprüfung, die natürlich ganz oder teilweise auch maschinell erledigt werden kann. Sie zu kopieren, um festzustellen ob sie noch lesbar sind, ist eine Option. Dass es dazu keine Programme geben kann, die reparieren, liegt auf der Hand. So wie es keine KI gibt, die "richtig" übersetzen kann und "Lücken" füllen kann (siehe so manches Gestotter auf YT), so wird es auch keine Programme geben, die fehlende Lücken in Texten oder Anderem sinnvoll schließen kann, wenn Sektoren (512 Byte) des Mediums einfach fehlen. Dann fehlen jedesmal 512 Byte komplett. Das kann man nicht ersetzen. Aber journalisierende Datei-Systeme mit Sicherungs-Mechanismen -wie zfs, xfs, btrfs- können das. Wobei btrfs noch zu jung ist und wenig erprobt ist, weshalb nach Redhat's Meinung es im professionellen Einsatz (noch?) nichts zu suchen hat. Habe ich gerade nochmal nachgelesen. Dort war zu lesen in RHEL 6 und RHEL 7 gab es immer wieder Updates, aber in RHEL 8 (8.10 von 2024) wurde es vollständig entfernt, war zu lesen. Oha! Mittlerweile gibt es Red Hat Enterprise Linux 10.1.

  • Ich hatte bei meinem alten Kisten-Rechner eine "Sterbe-Begleitung" einer Festplatte. Mit mc die Daten kopiert, und die beiden Dateien, die mc als "nicht lesbar" erkannte, einfach ignoriert. Sie spielten keine Rolle, und hätten auch gelöscht werden können. Spielte keine Rolle, ich hatte noch ein Backup. Aber, und das war der Erkenntnisgewinn, der Kopier-Prozess mit mc zeigt das sehr schön an, und bietet Knöpfe an, mit dem Problem umzugehen. Danach wurde die Kiste mit fx-4100 und Linux Mint drinne, die 2016 bis 2025 gute Dienste tat, an den Straßenrand gestellt, wo sie innerhalb von einer Stunde von Jemandem mitgenommen wurde. Da hat der Rechenknecht vielleicht Jemanden noch glücklich gemacht. :) der hoffentlich noch eine Festplatte hatte.

  • Es gibt da ein Tool Namens "Czkawka", gibt es auch in der Anwendungsverwaltung als Flatpak, hier lassen sich Dateien usw. vergleichen und auch explizit nach defekten Dateien suchen, allerdings nur PDF, Ton, Archiv und Bild Dateien, evtl. hilft das ja schon mal. :)

    Ich habe Czkawka bzw. Krokiet gerade ausprobiert. Die Suche nach defekten Dateien scheint sich auf Bilder zu beschränken. Videos und andere Dateitypen wurden bei meinem Test einfach ignoriert. Aber Bilder mit fehlerhafter Kodierung oder vorzeitigem Abbruch beim Lesen werden gefunden. (Ich habe noch einen alten, teils defekten USB-Stick mit alten Bildern und Videos. Ideal zum Testen von Defekten).

    Das Projekt macht einen guten Eindruck auf mich, es wird noch aktiv entwickelt, alles ist offen. Das Readme enthält auch Vergleiche zu ähnlichen Tools wie DupeGuru. Es hat sogar eine API, auf die andere Projekte (z.B. Schluckauf) aufsetzen können.

    Zotac ZBox ID91: Zorin OS 18 (GNOME) und GuideOS 1.0
    Geekom Mini IT11: Fedora 44 Silverblue (GNOME)
    Macbook Pro 2015: Fedora 43 Workstation (GNOME)

  • Ich fand dieses Tool nicht mehr. ;( Es ist wohl zu speziell oder das gibt es nicht mehr. ;(

    Werde die HDs (NTFS) unter Windows (HBCD) mit "chkdsk /r" (sektorweise Prüfung) per CMD ab und zu prüfen. Vielleicht finde ich dieses Tool noch. Bei meiner Suche fiel mir auf, daß viele sowas suchen.

    Hintergrund: 2 USB-Sticks hatten beim lesen Fehler, 1 hab ich gleich vernichtet. Für meine Backups hab ich etliche HDs (per Dockingstation), eine der Älteren hat 200GB (damals Hightech - von den PATA-HDs gar nicht zu reden :D). Beim Backup wird ja nur das Inhaltsverzeichnis gelesen und das sagt nichts über die Lesbarkeit der Datei aus.

    Wollte das mal für andere mitteilen. :)

  • Beim Backup wird ja nur das Inhaltsverzeichnis gelesen und das sagt nichts über die Lesbarkeit der Datei aus.

    Na das wäre ein tolles Backup, welches nur das Inhaltsverzeichnis liest und davon ein Backup macht ;) Die Software, die Backups so macht hätte auch den großen Vorteil, ganz schnell fertig zu sein.

    Mint Mate auf ASUS Zenbook Flip UX360U; Armbian auf Banana Pi; Mint Cinnamon auf MS Surface Go

  • An alle:

    Wer ein paar defekte Dateien hat und mir diese zukommen lässt: würde das mit checkit gern einmal überprüfen.

    Danke

  • An alle:

    Wer ein paar defekte Dateien hat und mir diese zukommen lässt: würde das mit checkit gern einmal überprüfen.

    Danke

    Ich habe das einfach geprüft, indem ich mit checkit die Prüfsummen gebildet, dann einige Dateien geändert und mit checkit auf Änderungen geprüft habe. Wäre nur interessant, was checkit bei Lesefehlern macht. Aber nicht lesbare Dateien kann man ja nicht verschicken, und selber machen wird auch schwierig 8|.

  • Na das wäre ein tolles Backup, welches nur das Inhaltsverzeichnis liest und davon ein Backup macht ;) Die Software, die Backups so macht hätte auch den großen Vorteil, ganz schnell fertig zu sein.

    Nein. :D

    Die meisten Dateien erfuhren ihr Backup vor Jahren und wurden dann nicht mehr angefasst. Wenn jetzt ein Backup gemacht wurde, wird nur das Inhaltsverzeichnis gelesen und/oder Größe. À la "ist unverändert da, braucht kein Backup". ;) (nur geänderte Dateien erfahren ein Backup)

    Es wird nie mehr geprüft, ob die Dateien noch lesbar sind.

  • Wie verpackt man denn nicht lesbare Sektoren? :D

    Festplatte öffnen, defekte Sektoren herausschneiden und in einen Karton packen. Am besten noch ein Schleifchen drum herum. Bei SSDs einfach den defekten Chip auslöten. 8o

  • Oder ein ISO-Abbild der gesamten Festplatte erstellen. Dabei werden die defekten Sektoren mitkopiert.

    Mainboard: MSI Z170-A Pro

    Prozessor: Intel i7 6700K

    Grafikkarte: AMD RX 7800 XT

    OS: EndeavourOS

    Desktop: KDE

  • Dabei werden die defekten Sektoren mitkopiert.

    Ja, aber als lesbare Bereiche. Man kann den Lesefehler nicht einpacken.

    Mint Mate auf ASUS Zenbook Flip UX360U; Armbian auf Banana Pi; Mint Cinnamon auf MS Surface Go

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!