Datei kopieren = bitgleich?

Wenn beim Dateien kopieren so viele Fehler passieren würden, würde sich 
keine Datei mehr öffnen lassen, denn ein einziges kaputtes Bit in einem 
"nicht-trivalen" Format wie .jpeg , .exe , .doc ... würde die Datei 
unbrauchbar machen. Daher werden beim kopieren/downloaden/... zB 
Checksums verwendet, um eine korrekte Übertragung zu gewährleisten.

Es gibt viele Stellen an denen Bitfehler passieren koennrn. Am 
haeufigsten sind das lange, schnelle Uebertragungsstrecken, zB das 
Internet. Deshalb werden dort auf der Bitsicherungsschicht in der Tat 
Pruefsummen verwendet, siehe Ethernet.
Was auch passieren kann sind Probleme mit Speicher, daher gibt es ECC 
RAM (v.A. in Servern und Workstations) und Pruefsummen im Flash Chip/HDD 
Controller.
Wenn bei deinen bekannten haeufig Bitfehler vorkommen kann das an 
defektem Arbeitsspeicher liegen, vielleicht mal in die Richtung suchen?

Highway Crossin Frog schrieb:
> sie immer noch bitgleich sind?

Bei Dateisystemen, die die Länge der Datei bytegenau festhalten (es gab 
auch mal andere, z.B. CP/M), muss auch der Inhalt exakt übereinstimmen. 
Auf dem Massenspeicher, z.B. Festplatte, wird gegen Fehler mit CRC 
gesichert, auf den Übetragungsstrecken, z.B. Ethernet, ebenfalls. Das 
funktioniert sehr zuverlässig zumindest in dem Sinn, dass Fehler erkannt 
und gemeldet werden.

Natürlich kann die Datei auf der Festplatte nach dem Kopieren fehlerhaft 
werden (wird erkannt) oder es tritt ein Fehler im RAM-Speicher auf - der 
wird leider nicht sicher erkannt, da nur Server mit CRC ausgestattet 
sind.

Hat man öfter mal unerklärliche Fehler, so sollte man als erstes eine 
Memtest-Boot-CD erstellen und mal ein paar Stunden laufen lassen - hat 
bei mir beim Backup auftretende Fehler beseitigt (nach dem Austausch des 
fehlerhaften Speichers natürlich).

Georg

Georg schrieb:
> Natürlich kann die Datei auf der Festplatte nach dem Kopieren fehlerhaft
> werden (wird erkannt)

von wem soll das denn erkannt werden? Aus den Grund wurde bei einigen 
Filesystem ja erst eine Prüfsumme eingebaut, weil es nicht erkannt 
wurde.

http://en.wikipedia.org/wiki/Comparison_of_file_systems

Beim TotalCommander kann man für das sichere Kopieren oder Verschieben 
von Dateien einfach ein  Häkchen bei Verifizieren setzen. Dann wird 
gleichzeitig immer ein CRC-Check ausgeführt.

http://www.chip.de/downloads/Total-Commander_12992663.html

Die Shareware läuft ohne Einschränkungen mit einem NagScreen beim Start 
auch Nicht Registriert im ewigen Testmodus über die 30 Tage weiter.

;)

prg schrieb:
> Beim TotalCommander kann man für das sichere Kopieren oder Verschieben
> von Dateien einfach ein  Häkchen bei Verifizieren setzen. Dann wird
> gleichzeitig immer ein CRC-Check ausgeführt.

bringt aber nichts, wenn die Festplatte schon das falsche liefert. Damit 
kann man nur sicherstellen, das das geschrieben identisch mit den 
gelesenen ist. Aber nicht das das gelesene auch stimmt.

Peter II (Gast) schrieb:

prg schrieb:
>> Beim TotalCommander kann man für das sichere Kopieren oder Verschieben
>> von Dateien einfach ein  Häkchen bei Verifizieren setzen. Dann wird
>> gleichzeitig immer ein CRC-Check ausgeführt.

> bringt aber nichts, wenn die Festplatte schon das falsche liefert. Damit
> kann man nur sicherstellen, das das geschrieben identisch mit den
> gelesenen ist. Aber nicht das das gelesene auch stimmt.

Der Einwand ist aber Käse. Es gilt sicherzustellen, dass das die Kopie 
mit dem Original übereinstimmt und GENAU DAS wird damit gewährleistet. 
Wenn du natürlich bereits deinem Original nicht traust ist sowieso alles 
zu spät. Nur wie soll ich mir das jetzt vorstellen? Was kann deine PC HW 
dafür, wenn bereits das zu kopierende Bild auf der Speicherkarte 
fehlerhaft sein soll? Dann hast du ein Problem mit deiner CAM und nicht 
mit dem PC.

prg schrieb:
> Der Einwand ist aber Käse. Es gilt sicherzustellen, dass das die Kopie
> mit dem Original übereinstimmt und GENAU DAS wird damit gewährleistet.

nein wird es nicht, wenn du schon das Original nicht sauber lesen 
kannst.

> Nur wie soll ich mir das jetzt vorstellen? Was kann deine PC HW
> dafür, wenn bereits das zu kopierende Bild auf der Speicherkarte
> fehlerhaft sein soll?
und was ist wenn die Festplatte oder Speicherkarte fehlerhafte Daten 
liefert?

> Dann hast du ein Problem mit deiner CAM und nicht mit dem PC.
es kann beides sein, im das Problem sicher zu lösen, müsste man bei 
ersten erzeugen einer Datei gleich die Prüfsumme mit wegschreiben. Nur 
so kann man sicherstellen, das sie nie etwas ändert.

Aus dem Grunde benutze ich unter Windows noch häufig den xcopy /v 
Befehl, weil damit jede geschriebene Datei mit der Ursprungdatei 
verglichen wird.
Macht das der normale Windows Drag-n-Drop-Kopiervorgang auch ?


prg schrieb:
> Beim TotalCommander kann man für das sichere Kopieren oder Verschieben
> von Dateien einfach ein  Häkchen bei Verifizieren setzen. Dann wird
> gleichzeitig immer ein CRC-Check ausgeführt.

Peter II (Gast) schrieb:

prg schrieb:
>> Der Einwand ist aber Käse. Es gilt sicherzustellen, dass das die Kopie
>> mit dem Original übereinstimmt und GENAU DAS wird damit gewährleistet.

> nein wird es nicht, wenn du schon das Original nicht sauber lesen
> kannst.

Dazu hast du mehrere Möglichkeiten. Zum einen über die CAM per USB-Kabel 
und zum anderen durch externes Auslesen der Speicherkarte mittels einer 
unzähligen CARD-Reader. Das beides dir falsche Dateien beim Lesen 
liefert kommt bei dir wo vor?

> Dann hast du ein Problem mit deiner CAM und nicht mit dem PC.
> es kann beides sein, im das Problem sicher zu lösen, müsste man bei
> ersten erzeugen einer Datei gleich die Prüfsumme mit wegschreiben. Nur
> so kann man sicherstellen, das sie nie etwas ändert.

Das ERSTE Erzeugen der Datei geschieht in der CAM. Was soll daran 
fehlerhaft sein, solange deine CAD nicht kaputt ist?

Matthias (Gast) schrieb:

> Aus dem Grunde benutze ich unter Windows noch häufig den xcopy /v
> Befehl, weil damit jede geschriebene Datei mit der Ursprungdatei
> verglichen wird.

Wäre mir viel zu unbequem. Zu Win9x Zeiten wo die DOSShell noch öfter 
wichtig war habe ich das auch so gemacht. Mit so einem Commander lässt 
sich ein Verzeichnisvergleich/Synchronisierung viel übersichtlicher und 
einfacher bewerkstelligen.

> Macht das der normale Windows Drag-n-Drop-Kopiervorgang auch ?

Checksummen überprüfen? Eher nicht ..

Vielleicht mit Zusatzsoftware. Gibt ja nahezu für alles irgendwelche 
netten Tools.

> Das ERSTE Erzeugen der Datei geschieht in der CAM. Was soll daran
> fehlerhaft sein, solange deine CAD nicht kaputt ist?

arrg "CAD" .. CAM latürnich.

;)

Das Problem mit fehlerhaft kopierten Dateien gab es früher mal bei AMD 
Board aufgrund eines HW-Fehlers in der Southbridge eines bestimmten 
Chipsatzes. Das trat aber nur bei heftigem Datenverkehr (hoher 
Auslastung) auf. Wurde durch eine Änderung der Chipsatztreiber dann 
behoben.

Bei jedem hin und herschieben werden einzelne Bits abgerieben. Je nach 
Material der Festplatten, Kabel,... ist die Abnutzung schneller oder 
langsamer. Um dem gegenzuwirken gibt es spezielle Bitgleitmittel damit 
die Bits besser durchflutschen und nicht abgehobelt werden. Abgehobelte 
Bits können auch die Leitungen verstopfen, deshalb wird die 
Übertragungsgeschwindigkeit mit der Zeit auch langsamer. Hier hilft ab 
und an die Leitungen zu putzen dafür gibt es spezielle Kabelreiniger, 
Ultraschallrüttler wo man das ganze Gerät reinstellt und die Bits 
rausgerüttelt werden.

prg schrieb:
> Das ERSTE Erzeugen der Datei geschieht in der CAM. Was soll daran
> fehlerhaft sein, solange deine CAD nicht kaputt ist?

das schreiben auf dem Flash? Auch diese haben eine Fehlerquote!

> Dazu hast du mehrere Möglichkeiten. Zum einen über die CAM per USB-Kabel
> und zum anderen durch externes Auslesen der Speicherkarte mittels einer
> unzähligen CARD-Reader. Das beides dir falsche Dateien beim Lesen
> liefert kommt bei dir wo vor?
wenn der Flash fehlerhaft arbeitet, liefert beide das gleiche falsche 
Ergebnis.


Bei (sterbenden) Festplatte kommt es vor, das man sie ohne Fehler 
auslesen kann, aber die Daten am ende falsch sind. Und ja größer die 
Festplatten werden desto höher ist die Wahrscheinlichkeit das Fehler 
nicht bemerkt werden.

Uhu Uhuhu schrieb:
> Von der Platte - die meldet einen Bad Sector.

nein leider nicht immer. Das bit kann auch im Ram vom 
Festplattencontroller umkippen.

Uhu Uhuhu schrieb:
> Von der Platte - die meldet einen Bad Sector.

das macht sie aber nur wenn die CRC nicht stimmt, leider erkennt man mit 
der CRC nur 1 oder 2 bit Fehler. Wenn ein paar mehr bits falsch sind, 
kann die CRC wieder stimmen.

Man müsste einen Hash verwenden und das Problem weiter zu minimieren.

Peter II (Gast) schrieb:

prg schrieb:
>> Das ERSTE Erzeugen der Datei geschieht in der CAM. Was soll daran
>> fehlerhaft sein, solange deine CAD nicht kaputt ist?

> das schreiben auf dem Flash? Auch diese haben eine Fehlerquote!

Für meine Begriffe theoretisierst du hier zu viel. Schlechte Aufnahmen 
entstehen i.a. nicht durch die Kamera, sondern durch den der auf den 
Auslöser drückt.

>> Dazu hast du mehrere Möglichkeiten. Zum einen über die CAM per USB-Kabel
>> und zum anderen durch externes Auslesen der Speicherkarte mittels einer
>> unzähligen CARD-Reader. Das beides dir falsche Dateien beim Lesen
>> liefert kommt bei dir wo vor?

> wenn der Flash fehlerhaft arbeitet, liefert beide das gleiche falsche
> Ergebnis.

Wenn, wenn, wenn. Wenn die Katze ein Pferd wäre, könnte sie die Bäume 
raufreiten.

Dann kauf dir eine anständige Flashkarte und nicht den billigsten Mist 
per Paypal beim Chinamann für 1 Euro.

> Bei (sterbenden) Festplatte kommt es vor, das man sie ohne Fehler
> auslesen kann, aber die Daten am ende falsch sind.

Kauf dir rechtzeitig eine neue Platte und gut ist. Entweder man traut 
seiner HW oder man holt sich besser neue.

Peter II (Gast) schrieb:


> das macht sie aber nur wenn die CRC nicht stimmt, leider erkennt man mit
> der CRC nur 1 oder 2 bit Fehler. Wenn ein paar mehr bits falsch sind,
> kann die CRC wieder stimmen.

> Man müsste einen Hash verwenden und das Problem weiter zu minimieren.

Wenn du so misstrauisch bist lass dir halt md5 oder sha Prüfsummen von 
all deinen Dateien generieren und bewahre die irgendwo mehrfach 
redundant auf. Das hilft gegen Bitparanoia bestimmt.

Sven B. (scummos) schrieb:

prg schrieb:
>> Kauf dir rechtzeitig eine neue Platte und gut ist. Entweder man traut
>> seiner HW oder man holt sich besser neue.
> Diese Sichtweise ist Unsinn.

Nö.

> Auch gute Hardware kann jederzeit auf
> unerwartete Weise kaputt gehen.

Morgen kann dich ein Erdbeben verschlingen oder ein Eisbrocken fällt dir 
aufs Hirn. Nur wie wahrscheinlich wird das wohl sein?

> "Ich kaufe die zweitbilligste SD-Karte
> und werde deshalb nie Probleme mit schleichendem Datenverlust haben" ist
> nicht die Wahrheit.

Wenn du unter "schleichendem Datenverlust" leidest solltest du mal deine 
HW erneuern.

Sven B. (scummos) schrieb:

> Auch gute Hardware kann jederzeit auf
> unerwartete Weise kaputt gehen.

Im übrigen hat man für solche Krisenherde ein Gegenmittel schon längst 
erfunden. Das nennt sich Daten-Backup.

Schon mal gehört?

prg schrieb:
> Wenn, wenn, wenn. Wenn die Katze ein Pferd wäre, könnte sie die Bäume
> raufreiten.

oder man kennt das Risiko und entscheidet selber wie man damit umgeht. 
Du ignorierst es.

http://www.it-administrator.de/themen/storage/fachartikel/111409.html
http://en.wikipedia.org/wiki/Data_corruption

A. K. schrieb:
> Das ist ein wenig mehr als bloss eine CRC für 1-Bit Fehler am Werk.

aber auch das hilft nicht.

http://en.wikipedia.org/wiki/Data_corruption
[...]
As another example, a real-life study performed by NetApp on more than 
1.5 million HDDs over 41 months found more than 400,000 silent data 
corruptions, out of which more than 30,000 were not detected
[...]

prg schrieb:
> Wenn du unter "schleichendem Datenverlust" leidest solltest du mal deine
> HW erneuern.

und woran merkt man den "schleichendem Datenverlust"? Schaust du dir 
jeden Tag alles Bilder und Filme auf der Festplatte an um nach defekten 
bits zu suchen?

Sven B. (scummos) schrieb:

> Das Backup bringt dir gar nix, wenn du es beim letzten Erneuern mit
> kaputten Daten überschrieben hast ohne es zu merken.

Und das kommt bei dir wie oft vor?

Hortest du Abschusscodes für Nukleare Sprengsätze oder sonst 
irgendwelche für die Menschheit überlebenswichtige Datensätze? Die 
solltest du vom Beginn der Erzeugung an mehrfach redundant in 
geschützten Räumen aufbewahren und gleichzeitig in die Cloud 
hinterlegen, aber nicht ohne den ALLEINIGEN Zugriff darauf NUR VON DIR 
SICHERSTELLEN zu können.

Ich fürchte nur an diesem Problem wirst du verzweifeln.

Am besten trennst du dich von all deiner Technik. Die ist nicht sicher 
in den Griff zu kriegen. Never!

Peter II (Gast) schrieb:

> und woran merkt man den "schleichendem Datenverlust"?

Wenn du einen "schleichenden Datenverlust" bereits annimmst wirst du 
wohl auch einen hinreichenden Grund dafür haben oder?

> Schaust du dir
> jeden Tag alles Bilder und Filme auf der Festplatte an um nach defekten
> bits zu suchen?

Nö. Ich leide nicht unter Paranoia. Ich war selber mal betroffener vom 
AMD South Chip Bug beim VIA 686B Chipsatz (das Board habe ich noch). Da 
hatte ich diese Einstellung eine Zeitlang. Der Fehler zeigte sich aber 
nur sporadisch, jedoch konnte ich ihn reproduzieren bei künstlich hoher 
Auslastung. Das mit der "Paranoia" legte sich aber zum Glück wieder.

Meine >10 Jahre alten Bilder auf der FP sehen noch genauso aus wie 
früher. Die Filmchen von damals laufen auch noch, sind aber vereinzelt 
in der Qualität inzwischen nicht mehr zeitgemäß (noch einiges per 
avi-Capturing in VGA mit damals vergleichsweise schwachbrüstigem 
Rechner) und somit eher für die Tonne bzw. nostalgisch.

Offiziell sollten sie gleich sein, da:
1. Die Daten auf einem Datenträger mit Prüfsummen gesichert sind.
2. Der Transportweg, Prinzip bedingt sehr Fehleranfällig, mit Prüfdaten
   versehen ist.
3. Die Daten auf dem Ziel, ebenfalls überprüfbar sind.

Insbesondere Punkt drei beinhaltet einen ganzen Sack voll Pferdefüße.

Beispiel: Du nimmst die billigen CD's und machst einen Flotten
          Heinrich (kein verify), dann kann's schon mal holprig
          werden.

P.S. Der Hersteller der CD wird, falls Feststellbar, Dir natürlich
     gerne einen Ersatzdatenträger liefern.

Sven B. (scummos) schrieb:

> Und ja, ich hatte schon z.B. JPEG-Bilder die jahrelang in einem Ordner
> lagen und dann plötzlich halb grün waren.

Sowas habe ich noch nie erlebt. Wenn ein USB-Stick den Geist aufgab war 
darauf mehr oder weniger alles weg oder eine FP-Partition war nicht mehr 
lesbar mit Teildatenverlust. Aber halbgründe Bilder? Dafür hat man seine 
Backups auf unterschiedlichen Medien.

Sven B. (scummos) schrieb:

prg schrieb:
>> Peter II (Gast) schrieb:
>>
>>> und woran merkt man den "schleichendem Datenverlust"?
>>
>> Wenn du einen "schleichenden Datenverlust" bereits annimmst wirst du
>> wohl auch einen hinreichenden Grund dafür haben oder?

> Die Realität ist dass der schleichende Datenverlust immer passiert

Ist das eine Annahme oder eine gesicherte Erkenntnis? Wenn das (d)eine 
gesicherte Erkenntnis ist, dann würde ich darauf mit redundanter 
Speicherung reagieren.

> und
> du ihn nur meist nicht bemerkst weil du anteilig ziemlich viele Daten
> hast die du nie bit-genau anschaust.

Sorry, aber Bitparanoia ist nicht mein Ding.


Sven B. (scummos) schrieb:

prg schrieb:
>> Aber halbgründe Bilder? Dafür hat man seine
>> Backups auf unterschiedlichen Medien.

> ... die dir aber nichts nützen, wenn du sie vor einem halben Jahr
> erneuert hast und der Fehler vor fünf Jahren unbemerkt aufgetreten ist.
> Das ist doch gerade der Punkt, um den es geht.

Und gerade das ist doch an den Haaren herbei konstruiert. Entspricht 
jedenfalls nicht meiner Erfahrung.

Ich kann das Thema auch nochmals anders beleuchten. Was kümmert dich die 
Sorge in einer Bilddatei mit 8, 12, 16 oder gar 24 Millionen Pixel, wenn 
irgendwo EIN Pixel einen Bitfehler hat? Werden deine Aufnahmen dadurch 
unbrauchbar?

Überlege mal wieviel Dateien Windows als OS permanent beackert (lesen, 
schreiben). Glaubst du das würde noch absturzfrei funktionieren, wenn da 
andauernd Bitfehler in den DLLs oder EXEs auftreten würden?

Irgendwie erinnert mich das ganze hier an lustige Schulhofdiskussionen, 
als Ronny Reagan sein "dolles" SDI damals der Welt vorstellte. Da ging 
bei uns eine wilde Diskussion um Bitkipper um. Die Welt am atomaren 
Abgrund, weil NIEMALS sichergestellt werden kann, nicht einem zufälligen 
Bitkipper in der Software solcher Verteidigungssysteme anheim zu fallen. 
Damals hieß es pro ca. 1 Mio Bytes ein gekipptes Bit.

Das blöde ist nur, wir leben immer noch. Wie das?

Uhu Uhuhu schrieb:
>> Man müsste einen Hash verwenden und das Problem weiter zu minimieren.
>
> ...einem Problem, das offensichtlich keines ist.

deswegen gibt es auch die Artikel (siehe oben) im Netzt. Auch die Macher 
von ZFS habe das nur als langerweile dien Prüfsumme eingebaut.

Wie kannst könnt ihr nur behaupten das das Problem keines ist, aber 
anderseits überhaupt keine Möglichkeit habt es zu prüfen?

Ja, man kann mit dem Problem leben (mache ich auch) aber man sollte 
wissen das es das Problem gibt.
Und wenn ihr doch mal Daten über einen längen Zeitraum aufheben müsst 
und diese Daten 100% korrekt sein müssen, dann kostet es auch keinen 
Aufwand zusätzlich eine SHA1 Datei anzulegen. Und bei jeden Backup prüft 
man ob die Prüfsumme nicht richtig ist.

prg schrieb:
> Ich kann das Thema auch nochmals anders beleuchten. Was kümmert dich die
> Sorge in einer Bilddatei mit 8, 12, 16 oder gar 24 Millionen Pixel, wenn
> irgendwo EIN Pixel einen Bitfehler hat? Werden deine Aufnahmen dadurch
> unbrauchbar?

schon mal was von Metadaten gehört? Was ist wenn das Bild auf einmal 
2048pixel breiter ist? Dann ist nicht mehr erkennbar.

Oder eine Zip-Datei. Ein falschen Bit und du bekommst CRC-Fehler beim 
entpacken und der Inhalt ist nicht mehr lesbar.

Peter II (Gast) schrieb:

> Und wenn ihr doch mal Daten über einen längen Zeitraum aufheben müsst
> und diese Daten 100% korrekt sein müssen, dann kostet es auch keinen
> Aufwand zusätzlich eine SHA1 Datei anzulegen. Und bei jeden Backup prüft
> man ob die Prüfsumme nicht richtig ist.

Eben. Dann mach das doch einfach. Fass das Zeug in einem Archiv zusammen 
und speichere dazu die Prüfsumme ab und gut ist.

Peter II schrieb:
> Und wenn ihr doch mal Daten über einen längen Zeitraum aufheben müsst
> und diese Daten 100% korrekt sein müssen, dann kostet es auch keinen
> Aufwand zusätzlich eine SHA1 Datei anzulegen. Und bei jeden Backup prüft
> man ob die Prüfsumme nicht richtig ist.

Und dann weißt du, daß dein Backup kaputt ist. Und dann? Aus dem Hash 
kannst du die Daten nicht wiederherstellen.

Deswegen nimmt man dafür auch keinen Hash, sondern einen low density 
parity code oder Reed-Solomon oder ähnliches.

Siehe parchive.

prg schrieb:
> Eben. Dann mach das doch einfach. Fass das Zeug in einem Archiv zusammen
> und speichere dazu die Prüfsumme ab und gut ist.

was ich mache ist doch egal, es ging hier um die Frage ob eine Datei 
immer 100% korrekt kopiert wird und das ist nicht der Fall. Es gibt zu 
viele stellen an denen die Datei beschädigt werden kann und dafür reicht 
es nicht aus sie nach dem Kopieren noch einmal zu vergleichen.

Peter II (Gast) schrieb:

> schon mal was von Metadaten gehört? Was ist wenn das Bild auf einmal
> 2048pixel breiter ist? Dann ist nicht mehr erkennbar.

Dann gibt es immer noch die Möglichkeit solche Dateien zu reparieren. 
Aber wieso glaubst du, dass ausgerechnet dein Bitkipper den Dateiheader 
betreffen muss? Das ist so wahrscheinlich wie wieviel richtige im Lotto?

> Oder eine Zip-Datei. Ein falschen Bit und du bekommst CRC-Fehler beim
> entpacken und der Inhalt ist nicht mehr lesbar.

Na und? Du hast die Datei doch noch mindestens einmal woanders 
gespeichert oder etwa nicht?

Ach du meinst du hättest auf zwei unterschiedlichen Medien an genau der 
gleichen Stelle deinen Bitkipper?

Du solltest Lottoscheine ausfüllen gehen.

prg schrieb:
> Ach du meinst du hättest auf zwei unterschiedlichen Medien an genau der
> gleichen Stelle deinen Bitkipper?

Wieso an der gleichen Stelle? Zwei unterschiedlich kaputte Dateien 
bringen dir auch keine heile Datei zurück.

Ist aber lustig zu sehen, wie Blinde von Farbe reden.

Bitkipper/Bitrot gibt es auf allen Ebenen: im RAM (viel öfter als man 
denken würde), auf Magnetspeichermedien, in Flash. Praktisch überall.

Peter II (Gast) schrieb:

prg schrieb:
>> Eben. Dann mach das doch einfach. Fass das Zeug in einem Archiv zusammen
>> und speichere dazu die Prüfsumme ab und gut ist.

> was ich mache ist doch egal,

Achso, na dann.

> es ging hier um die Frage ob eine Datei
> immer 100% korrekt kopiert wird und das ist nicht der Fall.

Doch ist es. DAS ist der Regelfall. Du erhebst eine seltene Ausnahme zum 
Regelfall und konstruierst daraus folglich eine Argumentationskette 
schlimmer annahmen. Genauso gut könnte man auf diese Art den 
Bundesbürgern die Gefahr schlimmer Erdbeben in Deutschland vorhalten, 
weil es keine ausreichenden Schutzräume für alle gibt und keiner 
ausschließen kann, dass nicht JEDERZEIT ein solches Erdbeben ausbrechen 
wird.

Was glaubst du wohl warum nicht mal der KatS-Schutz sich auf so ein 
Gleis begibt?

> Es gibt zu
> viele stellen an denen die Datei beschädigt werden kann und dafür reicht
> es nicht aus sie nach dem Kopieren noch einmal zu vergleichen.

Doch in der Regel reicht das völlig aus.

prg schrieb:
> Dann gibt es immer noch die Möglichkeit solche Dateien zu reparieren.
> Aber wieso glaubst du, dass ausgerechnet dein Bitkipper den Dateiheader
> betreffen muss? Das ist so wahrscheinlich wie wieviel richtige im Lotto?

genauso wie es Gewinner im Lotto gibt, gibt es "Verlierer" mit defekten 
Header.

Blöd nur wenn man jahrelang davon nichts gemerkt hat und fleißig von den 
defekten Daten ein Backup gemacht hat. Und die Festplatte mit dem Backup 
von vor 10Jahren schon entsorgt hat.

prg schrieb:
> Doch ist es. DAS ist der Regelfall.

in der Regel baue ich mit dem Auto auch kein Unfall, anschnallen tut ich 
mich aber auch.

In der Regel wird bestimmt bei dir auch nicht eingebrochen, warum 
schließt du deine Wohnung dann ab?

In der Regel sind Atomkraftwerke sicher ...

Sven B. (scummos) schrieb:

> Das sind relativ wenige Daten verglichen mit einer 500GB Fotosammlung.

Wen interessiert denn bei einer 500 Gigabyte Fotosammlung, ob irgendwo 
mal ein Bitchen nicht mehr stimmt?

Sorry, aber langsam wird's wirklich lächerlich. Glaubst du Papierfotos 
halten eine Ewigkeit? Irgendwann fällt dir mal eine Kaffeetasse darüber 
oder dein Lütter macht Hackfleisch aus einem deiner Bilder. So ist nun 
mal das Leben. Die Erde dreht sich weiter. Wenn dir die Frau weggelaufen 
ist willst du vielleicht die Hälfte deiner alten Bilder sowieso nicht 
mehr sehen. So what?

Einfach mal ein bisschen realistisch bleiben und nicht soviel 
herumtheoretisieren.

prg schrieb:
> Sorry, aber langsam wird's wirklich lächerlich.

Laecherlich ist nur, wie du dich voellig verrannt hast und nicht Ruhe 
geben kannst. Fakt ist und bleibt: Es gibt keine 100%ige Garantie und 
Fehler kommen in der Praxis vor. Wer sich davor schuetzen will, muss 
entsprechend hohen Aufwand betreiben. Ob das fuer ihn relevant ist, muss 
jeder Einzelne selbst entscheiden. Aber sicher nicht du fuer Andere.

prg schrieb:
> Wen interessiert denn bei einer 500 Gigabyte Fotosammlung, ob irgendwo
> mal ein Bitchen nicht mehr stimmt?

das muss jeder für sich entscheiden, aber wenn man kein Interesse daran 
hat kann man sie auch gleich löschen.

> Einfach mal ein bisschen realistisch bleiben und nicht soviel
> herumtheoretisieren.
Die Praxis hat die Fehler gezeigt nicht die Theroie!

Du lebst in der Theorie und hoffst das es dich nicht trifft, obwohl die 
Praxis zeigt das des es bei einer gewissen Datenmenge immer auftritt.

Heinz S. schrieb:
> Laecherlich ist nur, wie du dich voellig verrannt hast und nicht Ruhe
> geben kannst.

ACK.

Peter II schrieb:
> Du lebst in der Theorie und hoffst das es dich nicht trifft, obwohl die
> Praxis zeigt das des es bei einer gewissen Datenmenge immer auftritt.

Nein, Theorie und Praxis stimmen da völlig überein.

Im La-la-Land, wo man sich die Ohren und Augen zuhält, mag das anders 
sein.

Peter II (Gast) schrieb:

> in der Regel baue ich mit dem Auto auch kein Unfall, anschnallen tut ich
> mich aber auch.

Du fährst also tatsächlich Auto, obwohl du damit tödlich verunfallen 
kannst. Warum? Ist dir dein Leben nichts wert?

Was ist wohl wahrscheinlicher? Ein zufälliger Bitkipper in einer deiner 
zehntausend Bilddateien, ausgerechnet in deinem Lieblingsbild, 
ausgerechnet an einer kritischen Stelle im Dateiheader oder ein 
schlimmer Autounfall, wie er tagtäglich auf Deutschlands Straßen 
passiert?

Tipp: Wenn du vor Bitkippern Angst hast solltest du NIE WIEDER in ein 
Auto einsteigen!

> In der Regel wird bestimmt bei dir auch nicht eingebrochen, warum
> schließt du deine Wohnung dann ab?

Weil man das nun mal so macht hierzulande. In einer Hütte in Botswana 
wird das womöglich kulturell anders gehandhabt ..

> In der Regel sind Atomkraftwerke sicher ...

Bezogen auf deine angenommenen zufälligen Dateifehler aufgrund zufällig 
gekippter Bits scheint die Sicherheit im AKW nach allem was bekannt ist 
jedenfalls nicht bedroht. Da gibt es eine ganze Reihe anderer Fehler die 
die Sicherheit im AKW zumindest fraglich erscheinen lassen inkl. das 
Entsorgungsproblem des atomaren Mülls.

Aber das wolltest du sicher nicht diskutieren.

Gustav schrieb:
> Nein, Theorie und Praxis stimmen da völlig überein.

warum wurde dann aufwendig Studien der der Praxis gemacht? Die Theorie 
konnte nicht vorhersehen wie sich diese Fehler Auswirken.

Peter II schrieb:
> warum wurde dann aufwendig Studien der der Praxis gemacht? Die Theorie

Um die Theorie zu überprüfen, konkret, die Fehlerraten.

> konnte nicht vorhersehen wie sich diese Fehler Auswirken.

Das ist lächerlich.

@prg

Was willst du eigentlich?
Es ist doch schon mit links bewiesen das in der Praxis diese Art von 
Fehlern vorkommen.

Man kann diese Fehler ignorieren, aber zu behaupten das sie nicht 
vorkommen ist dumm.

Sven B. (scummos) schrieb:

> Liest du eigentlich was ich schreibe?

Langsam nicht mehr. Gähn!

>  - Für $privatperson mit $fotosammlung ist das Problem i.d.R. egal.

Aha!

> Trotzdem kann man es in der Realität beobachten, auch wenn es meist
> nicht schlimm ist. Das ist meine eigene Erfahrung.

Soll mal vorkommen. Spielt aber nicht die Rolle die du dem Thema hier 
beimisst.

>  - Trotzdem existiert das Problem und ich bin mir sicher dass z.B.
> YouTube auch über sowas nachdenken muss. Insofern verstehe ich nicht,
> was du für ein Problem damit hast dass hier über das Problem diskutiert
> wird.

Hier wird das Problem des TE diskutiert und nicht welche Probleme 
"YouTube" hat.

Ist mir ehrlich gesagt völlig schnuppe welche Probleme einer der großen 
Internetfirmen mit seinen Bilddateien hat. Da habe weder ich noch du 
einen Einblick. Also was soll das ganze? Bleibe beim einfach Thema des 
TE.

Heinz S. (Gast) schrieb:

> Laecherlich ist nur, wie du dich voellig verrannt hast und nicht Ruhe
> geben kannst.

Nö. Die Paranoiker geben hier keine "Ruhe".

> Fakt ist und bleibt: Es gibt keine 100%ige Garantie und
> Fehler kommen in der Praxis vor. Wer sich davor schuetzen will, muss
> entsprechend hohen Aufwand betreiben. Ob das fuer ihn relevant ist, muss
> jeder Einzelne selbst entscheiden. Aber sicher nicht du fuer Andere.

Aber auch DU nicht für mich! Aus meiner Sicht gibt es genügend andere 
Probleme. Wer Backups macht hat das besagte Problem nicht und wer es 
glaubt zu haben sollte mal über seine Datensicherheit neu nachdenken.

Paranoia ist jedenfalls kein guter Ratgeber.

prg schrieb:
> Wer Backups macht hat das besagte Problem nicht

Warum lügst du?

prg schrieb:
> Aber auch DU nicht für mich! Aus meiner Sicht gibt es genügend andere
> Probleme. Wer Backups macht hat das besagte Problem nicht und wer es
> glaubt zu haben sollte mal über seine Datensicherheit neu nachdenken.

du hast also immer noch nicht verstanden! Ein Backup von einer defekten 
Datei ist wertlos!

Ein Backup löst das Problem also nicht!

Peter II (Gast) schrieb:

> @prg

> Was willst du eigentlich?

Ich frage mich die ganze Zeit was DU eigentlich willst?

> Es ist doch schon mit links bewiesen das in der Praxis diese Art von
> Fehlern vorkommen.
> Man kann diese Fehler ignorieren, aber zu behaupten das sie nicht
> vorkommen ist dumm.

Der Punkt ist, du überzeichnest maßlos! Ich kenne das Problem selber 
früher vom Southbridge Bug. DA gab es mal so ein Problem wie du das hier 
schilderst. Seitdem ist mir das aber nicht mehr untergekommen.

Insofern habe ich im Gegensatz zu deinen theoretisierenden Annahmen 
damit schon mal zutun gehabt.

prg schrieb:
> Seitdem ist mir das aber nicht mehr untergekommen.

wie hast du das festgestellt? Augen zu und denken alles ist ok?

Peter II (Gast) schrieb:

> du hast also immer noch nicht verstanden! Ein Backup von einer defekten
> Datei ist wertlos!

Da musst du erstmal beweisen, dass das Backup defekt ist!

> Ein Backup löst das Problem also nicht!

Doch löst es. Du hast ja nicht nur EIN Backup oder?

Deine Argumentation deckt sich nicht mit der Realität!

prg schrieb:
> Da musst du erstmal beweisen, dass das Backup defekt ist!

nein, man muss vor dem Backup prüfen ob die Daten nicht defekt sind.

> Du hast ja nicht nur EIN Backup oder?
Ach so, 20 Backups einer defekten Datei sind natürlich viel besser.

prg schrieb:
> Deine Argumentation deckt sich nicht mit der Realität!

Dann lege von jeder Datei auf deiner Festplatte eine Prüfsumme an, dann 
prüfst du sie in einen Jahr noch einmal. Wenn du dann keinen Fehler 
findest dann scheint es das Problem wirklich nicht zu gegeben.

Aber solange du nichts prüfst, kann du lange behaupten das du nicht 
betroffen ist.

Peter II (Gast) schrieb:

prg schrieb:
>> Seitdem ist mir das aber nicht mehr untergekommen.

> wie hast du das festgestellt? Augen zu und denken alles ist ok?

Durch sporadische Dateivergleiche. Außerdem habe ich keine Bilder mit 
grünen Streifen oder sowas wie manch anderer hier in seinen alten Fotos 
bisher entdeckt.

Lustigerweise ist jetzt die Argumentation wohl wieder beim privaten 
Dateigebrauch angekommen.

Naja. Erinnert mich alles sehr an Spezies die einem einreden wollen das 
die Festplatte voll vor Viren sein muss, weil der Virenscanner ja NIE 
alle Viren findet. Ist immer das gleiche mit solchen Scheinargumenten. 
Irgendwas aus den Fingern saugen, dem anderen vor die Füße kippen mit 
dem Hinweis, nun beweise mal das Gegenteil. Solche Rituale sind 
hinlänglich bekannt und durchschaut.

prg schrieb:
> Durch sporadische Dateivergleiche.
also defekt mit defekt?

Und was ist wenn die Dateien unterschiedlich sind, welche ist denn die 
defekte oder sind beide defekt?

Genau für so etwas eine Prüfsumme erfunden.

>  Außerdem habe ich keine Bilder mit
> grünen Streifen oder sowas wie manch anderer hier in seinen alten Fotos
> bisher entdeckt.
du hast selber geschrieben, das die Wahrscheinlichkeit viel höher ist 
das einfach nur ein Pixel falsch ist, das sieht man nicht.

Peter II (Gast) schrieb:

> Dann lege von jeder Datei auf deiner Festplatte eine Prüfsumme an, dann
> prüfst du sie in einen Jahr noch einmal.

Die Arbeit kann ich mir sparen. Da kommt kein relevanter 
Informationsgehalt dabei heraus.

> Wenn du dann keinen Fehler
> findest dann scheint es das Problem wirklich nicht zu gegeben.

Ich weiß schon was mir wichtig ist und worauf ich ein besonderes 
Augenmerk lege. Prüf du tagtäglich deine Bits. Ich gehe da anders vor. 
Ich leide nicht unter Wahrvorstellungen über plötzlich verkrüppelte 
Dateien. Das hatte ich alles mal beim Southbridge Bug. Never ever.

Und jetzt ist mal Schluss mit den Kindereien hier. Die Bits im Rechner 
werden schon nervös.

:-)

prg schrieb:
> Die Arbeit kann ich mir sparen. Da kommt kein relevanter
> Informationsgehalt dabei heraus.

sehr sinnvoll, es gibt also ein Verfahren um nachzuweisen das du auch 
davon betroffen ist, aber du setzt es nicht ein weil du ja weist das du 
nicht betroffen bist.

Aber du hast recht, der Informationsgehalt ist nicht relevant, weil es 
schon statisch sehr wahrscheinlich ist das du auch davon betroffen ist. 
Das muss man nicht erst nachweisen.

Da hier ja offenbar die absolute Datensicherheit gefordert wird, hier 
ein Vorschlag:

Man nehme eine beliebige Anzahl an PCs, die jeweils ihre Daten im RAID1 
(Mirroring) auf - sagen wir mal 10 - Festplatten parallel speichern. 
Jeder Rechner ist mit jedem Vernetzt und vergleicht seine Daten ständig 
mit denen der anderen. Tritt ein Fehler auf, prüft jeder PC die Stelle 
und es gewinnt die Mehrheit.

Zur Sicherheit kann man natürlich auch noch die Leitungen zwischen den 
PCs redundant ausführen und die Daten mehrmals Senden.

Und so wird alles immer komplizierter und irgendwer aus einem 
Mikrocontroller-Forum wischt all das mit den Worten "Aber was ist, wenn 
meine Quelldatei defekt ist?" wieder weg :-)

1

Rezept:

Aber auch dafür gibt es natürlich eine Lösung: Wir stellen den 
Originalrechner, der die Daten erzeugt, mehrfach hin.

Falls er die Daten irgendwo her bekommt, stellen wir die entsprechende 
Datenquelle ebenfalls mehrfach zur Verfügung. Wenn diese ihre Daten 
wieder von irgendwo bekommt ->

1

rjmp Rezept

Und so haben wir schließlich ein paar Paralleluniversen auf unserer 
Einkaufsliste fürs Rechenzentrum stehen...