Moin Hab mir neulich mal Gedanken gemacht, ob Dateien ständig gleich bleiben, auch wenn man sie x mal hin und her schiebt. Kann es dann evtl. vorkommen, dass dann plötzlich z.B. Bit 10^7 nicht mehr 1 ist sondern 0 oder umgekehrt? Kann ich das irgendwie überprüfen? Wenn die Datei derart mutiert ist, dass ich sie nicht mehr öffnen kann ist es ja klar, aber was wenn nur ein paar bits invertiert sind?
Man kann einen CRC oder Hash wert rechnen.
ok, dazu bräucht ich aber mal die orginal Datei bzw. die intakte Datei oder?
wenn du nur wissen willst, ob sie OK ist, dann brauchst du nur eine Checksumme oder einen Hash. Willst du sie auch wieder herstellen, dann brauchst du die Datei 3mal, es könnte ja sein, dass bei der kaputten der hash oder die Checksumme genau passend mutiert ist. Das ganze kannst du natürlich unendlich fortsetzten, weil bei 3 Datein könnten ja auch 2 ungleichmäßig defekt sein...
Wenn ich mich recht entsinne, dann hab ich schonmal eine Meldung von Windows bekommen, dass eine Prüfsumme nicht stimmen würde. Obs die wirklich gibt, oder wie die aufgebaut ist, weiß ich nicht. Ziemlich sicher bin ich mir aber, dass bei Video CDs sowas nicht greift. Da kann ich mich entsinnen, dass nach dem 1:1 Kopieren der CD ein Programm welches bitweise die Files vergleicht, manchmal unterschiede entdeckte, ohne dass Windows einen Fehler gemeldet hat
Was es gibt ist die sogenannte Forward Error Correction, da wird ein Hamming Code gerechnet, es werden redundante Daten eingebaut, sodass einzelne oder mehrere Bitfehler erkannt und korrigiert werden koennen.
Ich glaube kaum, dass Windows selber eine Prüfsumme oder eine Forward Error Correction macht... Bei manchen Downloads (meistens irgendwo im Unix Umfeld) gibt es md5 Hashes dabei, womit man die Integrität der Dateien überprüfen kann. Wenn allerdings eine Datei beim Kopieren von A nach B Bitfehler aufweist, ist der md5 Hash noch das kleinste Problem...
Eine Disk has auf jedem sektor eine CRC und jedes Datenpacket ueber die Ethernet hat auch einen CRC. Das macht das Bios schon.
Ok. Aber wenn du tatsächlich mal einen CRC Fehler auf der Festplatte hast, brauchst du sowieso eine neue Festplatte ;-)
Die Lese/Schreib-Fehlerrate liegt im Bereich von 10^15 oder so. (Kann man im Datenblatt nachlesen). Das bedeutet, dass ohne Integritätsprüfung (und entsprechender Aktion) sehr wohl Daten verloren gehen. Beim Kopieren hat man zusätzlich das Risiko anderer Hardwarefehler im ähnlichen Bereich. Die magnetische Haltbarkeit ist aber ebenso begrenzt. Der beste Schutz ist ein RAID5 oder ein Filesystem vom Typ ZFS oder BTRFS als RAID. Auf letzteres warte ich ich auch schon seit Jahren. Leider hat es noch experimentellen Status.
Simon K. schrieb: > Bei manchen Downloads (meistens irgendwo im Unix Umfeld) gibt es md5 > Hashes dabei, womit man die Integrität der Dateien überprüfen kann. > > Wenn allerdings eine Datei beim Kopieren von A nach B Bitfehler > aufweist, ist der md5 Hash noch das kleinste Problem... Der wohl weit häufigste Fehler in dem Bereich ist, dass Binärdateien fälschlicherweise via FTP im Textmodus übertragen werden. Die MD5-Hashes haben in dem Kontext eher etwas mit der Erkennung von Anwender- als von Übertragungsfehlern zu tun. Ausserdem können so auch von Dritten Fehler wie z.B. abgeschnittene Dateien aufgrund von unbemerkten Verbindungsabbrüchen bereits beim Upload (der nicht immer interaktiv gemacht wird, und schnell für so etwas zusammengehackte Scripte neigen leider dazu, die Fehlerbehandlung zu vernachlässigen ;-). Wow wie Denn schrieb: > Eine Disk has auf jedem sektor eine CRC und jedes Datenpacket ueber die > Ethernet hat auch einen CRC. Das macht das Bios schon. Festplatten benutzen intern schon seit geraumer Zeit ausgefeilte Fehlerkorrekturmechanismen, ein einfacher CRC reicht da schon lange nicht mehr aus. Lesefehler werden da AFAIK heutzutage fest einkalkuliert, um die heutigen Datendichten überhaupt erreichen zu können. Nur die Fehlermeldung, wenn die Fehlerkorrektur mal nicht mehr ausreicht, spricht bis heute noch von CRC, da der Fehlercode eben irgendwann mal so definiert wurde. Was aber lange Zeit in vielen Fällen überhaupt nicht abgesichert wurde ist die Übertragung zwischen Rechner und Festplatte. Bei IDE gibt es erst seit der Einführung von UDMA einen CRC, davor gab es nichtmal Parity. Andreas
ZFS und BTRFS verwenden Prüfsummen, die meisten anderen gebräuchlichen Dateisysteme m.W. nicht. Andreas Ferber schrieb: > Der wohl weit häufigste Fehler in dem Bereich ist, dass Binärdateien > fälschlicherweise via FTP im Textmodus übertragen werden. Wer heute noch FTP verwendet verdient es nicht anders...
Andreas Schwarz schrieb: > Wer heute noch FTP verwendet verdient es nicht anders... Gibts da etwa eine alternative? Mein (und sicher nicht nur mein) Webhoster bietet mir ausschließlich FTP an um Dateien hochzuladen.
Andreas Schwarz schrieb: > Wer heute noch FTP verwendet verdient es nicht anders... FTP ist weiterhin vielfältig im Einsatz. Da die Trägerprotokolle darunter heutzutage stets abgesichert sind, teilweise auf mehreren Ebenen, ist das auch kein Problem. Die Ascii/Binary-Problematik hat damit nichts zu tun.
Andreas Schwarz schrieb: > ZFS und BTRFS verwenden Prüfsummen, die meisten anderen gebräuchlichen > Dateisysteme m.W. nicht. Wobei der Nutzen IMO recht begrenzt ist. Wenn z.B. ein Bit im RAM kippt, dann wird die Prüfsumme schon aus falschen Daten berechnet. Der grösste Teil der Kette, die hier durch die Dateisystem-Prüfsumme abgedeckt wird, ist heutzutage auch schon durch andere Checks recht gut versorgt (CRC32 bei SATA, SAS und PCI Express, FEC auf der Platte selbst). Sinnvoller ist das IMO auf Ebene der Anwendung, wie es z.B. bei git gemacht wird, da hier die Abdeckung sogar über verteilte Systeme hinweg lückenlos gemacht werden kann. So kann das u.U. sogar zur Aufdeckung mutwilliger Sabotage genutzt werden, wenn der Angreifer nicht gleichzeitig alle Kopien der Prüfsumme manipulieren kann. Im Zweifelsfall (wenn die Integrität und deren Nachweis wirklich wichtig ist) kann ich die meinetwegen sogar als Kleinanzeige in ein paar Tageszeitungen setzen und später im Archiv nachlesen, da wird eine Manipulation dann wirklich schwierig. > Wer heute noch FTP verwendet verdient es nicht anders... Totgesagte leben länger ;-) Leider hat man oft genug einfach nicht die Wahl, weder als Anbieter (weil die Kunden danach verlangen) noch als Kunde (weil der Anbieter nichts anderes unterstützt). Und wo bleibt der Nostalgiefaktor? ;-) Ich hol' meine Mails auch heute noch per UUCP ab... Andreas
Simon K. schrieb: > Ich glaube kaum, dass Windows selber eine Prüfsumme oder eine Forward > Error Correction macht... CDs und DVDs würden ohne ECC überaupt nicht vernünftig funktionieren.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.