Hallo zusammen, ich möchte 1TB an Daten (es sind lauter kleine Dateien nicht eine große) von einer externen USB2.0 HDD (NTFS) auf eine andere externe USB2.0 HDD (NTFS) Festplatte kopieren. Beide Platte sind herkömmliche mechanische HDDS und kein SSDs! Wichtig ist mir hierbei dass die Daten FEHLERFREI kopiert werden! Jetzt würde ich gerne ein Programm nutzen, dass eine Art Checksumme bilden kann und quasi nach dem Kopieren prüft ob alle Daten richtig geschrieben wurden. Was würdet ihr da empfehlen? Mein Betriebssystem ist Win7 (oder ist ein Live Linux evtl besser geeignet?). Oder wäre es evlt besser wenn man die zu lesende HDD (Sata HDD im externen USB2.0 Gehäuse) in den Desktop Rechner fest einbaut? Die Geschwindigkeit des Kopiervorganges ist mir nicht wichtig, wie gesagt es muss sichergestellt sein, dass die Kopie fehlerfrei ist. Falls jemand von euch da Erfahrung hat bitte melden. Danke ;)
Idee: Alles in ein Archiv, dann am Stück mit einem Dateimanager, der Dateien sofort schreibt und nicht erst buffert, nutzen zum Übertragen. Mir fällt spontan FlashFXP ein. Wenn eine zu kopierende Datei abbricht, dann kann man es einfach noch einmal versuchen und es macht da weiter, wo es aufgehört hat.
nimm das Windows eigene Robocopy, das kann alles was du willst, ist aber ein Kommandozeilen Programm Es gibt dazu eine GUI http://YARCGUI.wilkes.es mit der kannst du die Parameter einfach einstellen
Teracopy kann das z.B. https://www.codesector.com/teracopy Aber USB2 nach USB2 dauert bei der Datenmenge fast 1 Tag. Am besten beide intern verwenden und clonen.
Bit Kopierer schrieb: > Was würdet ihr da empfehlen? Total Commander, der prüft nach dem kopieren die Dateien komplett.
HyperMario schrieb: > Total Commander, der prüft nach dem kopieren die Dateien komplett. das musst du dann aber erst in der Konfig unter Kopieren/Löschen einstellen.. Haken bei Verifizieren nach dem Kopieren (MD5-Quersumme) einstellen. Robocopy ist an der Stelle deutlich besser, auch wenn ich TCMD schon seit Version 1.0 nutze
Bit Kopierer schrieb: > ich möchte 1TB an Daten (es sind lauter kleine Dateien nicht eine große) > von einer externen USB2.0 HDD (NTFS) auf eine andere externe USB2.0 HDD > (NTFS) Festplatte kopieren. > > Beide Platte sind herkömmliche mechanische HDDS und kein SSDs! > > Wichtig ist mir hierbei dass die Daten FEHLERFREI kopiert werden! > > Jetzt würde ich gerne ein Programm nutzen, dass eine Art Checksumme > bilden kann und quasi nach dem Kopieren prüft ob alle Daten richtig > geschrieben wurden. Was würdet ihr da empfehlen? rsync kann das. Für Windows gibt es das meines Wissens nach als Teil des cygwin Projekts. Falls die Übertragung über USB keine Fehler erkennen können sollte oder im RAW Modus durchgeführt wird und eine Fehlererkennung dabei weggelassen werden sollte, hilft allerdings das beste Programm nichts. Aber diese Frage können dir sicher die Elektroniker hier genauer beantworten. Ich glaube USB bietet so etwas wie error correction, CRC und verify für mass storage devices.
Aufgrund der Datenmenge wäre es aber dennoch besser, die Festplatten aus dem externen USB Gehäuse auszubauen und über SATA oder eSATA direkt an den Rechner anzuschließen. Über SATA geht das einfach viel schneller.
Nano schrieb: > Aufgrund der Datenmenge wäre es aber dennoch besser, die Festplatten aus > dem externen USB Gehäuse auszubauen und über SATA oder eSATA direkt an > den Rechner anzuschließen. > Über SATA geht das einfach viel schneller. Geschwindigkeit ist ihm nicht wichtig, die Datensicherheit ist wichtig.. dazu würde ich auf keinen Fall irgendeine HDD aus dem Gehäuse ausbauen, wer weiss was ihm dabei passiert und die Daten sind auf der Quelle defekt!!! Ich kann nur sagen Robocopy erfüllt seit vielen Jahren genau diese Anforderung, protokolliert alles was man will und arbeitet absolut zuverlässig ohne grafische GUI die beim kopieren sinnlos ist
Hallo Bit Kopierer, Bit Kopierer schrieb: > Jetzt würde ich gerne ein Programm nutzen, dass eine Art Checksumme > bilden kann und quasi nach dem Kopieren prüft ob alle Daten richtig > geschrieben wurden. Was würdet ihr da empfehlen? z.B. "MD5Summer". https://www.heise.de/download/search?terms=md5summer Du kopierst die Dateien mit dem Tool Deiner Wahl. Dann nutzt ein Programm wie "MD5Summer" um die Prüfsummen im Quellordner zu berechnen. Im nächsten Schritt überprüfst Du mit der Prüfsummendatei die Kopie im Zielordner. Es ist hilfreich, wenn sich Quelldatein und Zieldateien in einem Ordner befinden, zumindest für den Moment der Generierung der Prüfsummendatei und der anschließenden Überprüfung. > > Mein Betriebssystem ist Win7 (oder ist ein Live Linux evtl besser > geeignet?). Ich sehe keinen Mehrwert in einem Live-Linux-System. > > Oder wäre es evlt besser wenn man die zu lesende HDD (Sata HDD im > externen USB2.0 Gehäuse) in den Desktop Rechner fest einbaut? > > Die Geschwindigkeit des Kopiervorganges ist mir nicht wichtig, wie > gesagt es muss sichergestellt sein, dass die Kopie fehlerfrei ist. > > Falls jemand von euch da Erfahrung hat bitte melden. > > Danke ;)
:
Bearbeitet durch User
Problematisch beim Kopieren sind sehr viele kleine Dateien auf ein Medium ohne Write-Cache. Das dauert aufgrund der Transaktionen pro Datei ewig und drei Tage, liefert nicht annähernd die Byterate vom Interface.
Thomas S. schrieb: > HyperMario schrieb: >> Total Commander, der prüft nach dem kopieren die Dateien komplett. > > das musst du dann aber erst in der Konfig unter Kopieren/Löschen > einstellen.. Haken bei Verifizieren nach dem Kopieren (MD5-Quersumme) > einstellen. Direkt nach dem Kopieren zu vergleichen würde ich vermeiden. Dabei erwischt man doch nur die Daten aus einem der diversen Cache-Layer. Ich würde es ganz normal rüber kopieren und anschließend per Total Commander "Verzeichnisse synchronisieren"-Funktion einen Komplettvergleich nach Dateiinhalt starten. Da man dies "1 TB später" macht, kann man sich ziemlich sicher sein das man die tatsächlich geschriebenen Daten und nicht irgendwas in einem der Caches vergleicht.
Stefan P. schrieb: > Direkt nach dem Kopieren zu vergleichen würde ich vermeiden. Dabei > erwischt man doch nur die Daten aus einem der diversen Cache-Layer. > Ich würde es ganz normal rüber kopieren und anschließend per Total > Commander "Verzeichnisse synchronisieren"-Funktion einen > Komplettvergleich nach Dateiinhalt starten. Da man dies "1 TB später" > macht, kann man sich ziemlich sicher sein das man die tatsächlich > geschriebenen Daten und nicht irgendwas in einem der Caches vergleicht. und wieder Robocopy, dies nach dem kopieren ein 2. mal starten, dann werden die Dateine verglichen und nur unterschiedliche Dateien kopiert und wunderschön in einem Log dargestellt welche Dateien kopiert wurden
Noch eine Variante, die zugegebenermaßen auch recht lang dauert, dafür aber auch zukünftig defekte Dateien repariert werden können, wäre MultiPar. Damit kannst du Paritydaten erzeugen. xxcopy bietet sich aber auch an.
Stefan P. schrieb: > Direkt nach dem Kopieren zu vergleichen würde ich vermeiden. Dabei > erwischt man doch nur die Daten aus einem der diversen Cache-Layer. Unter linux wäre das Problem einfach zu lösen:
1 | sync; echo 1 > /proc/sys/vm/drop_caches |
Und zum vergleichen sha256sum. Oder cmp. Oder diff. Oder...
Das kostenlose FreeFileSync läuft bei mir für solche Fälle recht zuverlässig. https://freefilesync.org/
Thomas S. schrieb: > und wieder Robocopy, dies nach dem kopieren ein 2. mal starten, dann > werden die Dateine verglichen und nur unterschiedliche Dateien kopiert > und wunderschön in einem Log dargestellt welche Dateien kopiert wurden Ja wir hams ja begriffen... Dein Tool will halt einfach keiner.
Als fauler User habe ich öfter rar oder ein Prüfsummenprogramm benutzt und dann die paar Prüfzahlen verglichen. Es nützt aber wenig, nur Prüfzahlen zu vergleichen, wenn man vorher keine Recht hat, ALLE Dateien zu kopieren! Deswegen könnte ein komplettes Image besser sein.
Danke erstmal für die zahlreichen Rückmeldungen. Auch vielen Dank, dass die meisten hier verstanden haben, dass ich die Daten nicht möglichst schnell sondern SICHER kopieren will. Ein komplettes Image scheidet aus, da sich auf der Zielfestplatte bereits Daten befinden. Was mich jetzt noch interessieren würde: Welche Schnittstelle ist aufgrund Ihrer "Architektur" sicherer bei der Datenübertragung (USB2.0 oder SATA)? Ich denke da auf Bit Ebene und meine damit was passiert wenn eine Flanke auf der Schnittstelle falsch erkannt wird. Da gibt es bestimmt unterschiedlich Arten der Absicherung (CRC oder was weiß ich....) Die ganze Absicherung der Daten geschieht vermutlich auf Protokoll Ebene... nur was ist jetzt die geeignetste Schnittstelle wenn man Daten sicher kopieren will? USB oder Sata? Scheinbar scheint die Absicherung der Daten (USB und Sata) über CRC (oder was weiß ich alles ) ja nicht sicher zu funktionieren. Sonst würde es ja keine Softwareprogramme geben die prüfen ob die Daten richtig kopiert wurden... Man merkt schon... ich habe noch nie eine Sata oder eine USB Schnittstelle entworfen/programmiert ;D Aber hier gibts bestimmt einige die das schon gemacht haben :) Der Ausbau der HDDs aus den externen USB Gehäusen stellt kein Problem dar...
Bit Kopierer schrieb: > Welche Schnittstelle ist aufgrund Ihrer "Architektur" sicherer bei der > Datenübertragung (USB2.0 oder SATA)? Im Zweifelsfall würde ich sagen SATA.
Da du über USB "nur" eine weitere Ebene darauf legst (die Festplatte ist ja trotzdem per SATA an dem USB-SATA-Interface angeschlossen) wird der direkte Anschluss per SATA zuverlässiger - oder zumindest nicht weniger zuverlässig - sein. MfG, Arno
Bit Kopierer schrieb: > Ein komplettes Image scheidet aus, da sich auf der Zielfestplatte > bereits Daten befinden. Wenn Daten wirklich wertvoll sind, dann schafft man sie nicht nur auf ein Backup und benutzt verschiedene Methoden. Eine neue HD ist billiger als Ontrack.
Hallo Bit Kopierer, Bit Kopierer schrieb: > Danke erstmal für die zahlreichen Rückmeldungen. Auch vielen Dank, dass > die meisten hier verstanden haben, dass ich die Daten nicht möglichst > schnell sondern SICHER kopieren will. > > Ein komplettes Image scheidet aus, da sich auf der Zielfestplatte > bereits Daten befinden. > > Was mich jetzt noch interessieren würde: > > Welche Schnittstelle ist aufgrund Ihrer "Architektur" sicherer bei der > Datenübertragung (USB2.0 oder SATA)? Ich denke da auf Bit Ebene und > meine damit was passiert wenn eine Flanke auf der Schnittstelle falsch > erkannt wird. Da gibt es bestimmt unterschiedlich Arten der Absicherung > (CRC oder was weiß ich....) > > Die ganze Absicherung der Daten geschieht vermutlich auf Protokoll > Ebene... > nur was ist jetzt die geeignetste Schnittstelle wenn man Daten sicher > kopieren will? USB oder Sata? Deine Ansprüche an Vermeidung von Datenverfälschung legen nahe, dass Du Dir einen ZFS-basierten Server kaufst/baust. Dabei solltest Du dann auch die Backups nicht vergessen, denn für defekte zpools scheint es keine Recoverysoftware zu geben und die Profis nehmen dafür mutmaßlich fünfstellige Eurobeträge. Wenn Du nun von der Verfälschung durch die Schnittstelle sprichst, darfst Du auch das RAM nicht ignorieren. Das muss dann ECC-RAM sein.
Bit Kopierer schrieb: > Jetzt würde ich gerne ein Programm nutzen, dass eine Art Checksumme > bilden kann und quasi nach dem Kopieren prüft ob alle Daten richtig > geschrieben wurden. Was würdet ihr da empfehlen? Wenn es manuell angestoßen werden darf: https://www.exactfile.com/downloads/ und da die Version: 1.0.0.15 Beta
Sowohl SATA als auch USB spezifizieren für den Physical Layer eine Bitfehlerrate von < 1* 10^-12 . Also sind 16 Bitfehler für das Kopieren von 1 TB erlaubt, was inakzeptabel schlecht ist. Diese müssen daher in höheren Schichten von SATA bzw. USB erkannt und wiederholt werden. Aber ich habe keine Ahnung wie sich die beiden hier unterscheiden.
Blechbieger schrieb: > was inakzeptabel schlecht ist. Ich habe beim Kopieren von Videofiles unter Win7 mit USB3 diverse fehlerhafte Files gehabt. Am selben PC (Bootmanager) auf die selbe Platte mit USB2 unter XP gibt es keinerlei Ausfälle. Sieht nach einem Problem von USB aus - na jedenfalls schleppe ich nun Checksumdateien mit, an die eigentliche Ursache komme ich nicht heran.
Mad schrieb: > Thomas S. schrieb: >> und wieder Robocopy, dies nach dem kopieren ein 2. mal starten, dann >> werden die Dateine verglichen und nur unterschiedliche Dateien kopiert >> und wunderschön in einem Log dargestellt welche Dateien kopiert wurden > > Ja wir hams ja begriffen... Dein Tool will halt einfach keiner. Woran man sehr schön sehen kann, wie dumm doch die Welt ist. Denn das Tool bietet alle nur denkbaren Vorteile: - Es ist im System schon vorhanden. - Es ist umfassend getestet. - Es leistet alles, was in der konkreten Anwendung nötig ist (und noch einiges mehr, was hier bisher garnicht erwähnt wurde, es kann nämlich mit den ganzen NTFS-Spezialitäten korrekt umgehen, von komprimierten oder verschlüsselten Dateien über AFS und ACLs bis hin zu den diversen Möglichkeiten der Verlinkung innerhalb eines oder zwischen mehreren NTFS-Volumes). Für das Kopieren auf FS-Ebene von NTFS zu NTFS gibt's nichts Besseres.
Mad schrieb: > Thomas S. schrieb: >> und wieder Robocopy, dies nach dem kopieren ein 2. mal starten, dann >> werden die Dateine verglichen und nur unterschiedliche Dateien kopiert >> und wunderschön in einem Log dargestellt welche Dateien kopiert wurden > > Ja wir hams ja begriffen... Dein Tool will halt einfach keiner. Doch, ich. Ich habe den Beitrag nicht erstellt, erfreue mich aber über den Tipp, denn Robocopy kannte ich noch nicht. Es ist außerdem nicht sein Tool, sondern das von Microsoft. Ich finde es sinnvoll, gleich das vom Hersteller zu nehmen. Daher ist der Tipp gut. Auch wenn du das nicht hören willst.
paar Gedankengänge dazu: warum sollte eine Copy nicht fehlerfrei sein? In welchem Sinne sind hier "Fehler" gemeint? Dateien kaputt oder Kopierabbrüche? Oder fehlt am Ende etwas ohne dass es Fehlermeldungen gibt? man kann es u.U. haben, dass man z.B. versteckte Dateien unter Windows nicht kopiert. Wie sieht überhaupt die Qualität der Festplatten aus? Was sagen Crystaldisk (und Co)? wenn da eine Platte schon fehlerhafte Bereiche hat und es imme rmehr werden... Ihr mit Eurem mistigen Kram immer, ich kenne Euch!!! ;) WENN man das schon unter Win machen will, würde ich für das Kopieren den Rechner vom Web abklemmen und den Virenscanner abschalten. aber vorher aktualisieren, nicht dass der (oder anderes) mit irgendwelchen Mist-Meldungen dazwischen kloppt. ausserdem würde der Virenscanner bei jeder Datei immer erst noch gerne prüfen wollen, was damit los ist... kann man natürlich auch zum Anlass nehmen, das endlich mal zu checken :D Live-System... weiss man, ob das die Hardware wirklich effizient anspricht? nicht, dass das dadurch noch nen halben Tag länger dauert.
● J-A V. schrieb: > Oder fehlt am Ende etwas ohne dass es Fehlermeldungen gibt? > man kann es u.U. haben, dass man z.B. versteckte Dateien > unter Windows nicht kopiert. Auch nicht jede im Zugriff befindliche Datei wird immer zuverlässig kopiert und ob USB3 in jedem Fall sauber funktioniert, wäre noch zu klären. Manfred schrieb: > auf die selbe Platte mit USB2 unter XP gibt es keinerlei Ausfälle. Treiber ok, Kabel ok? Man sollte mal den Datenstrom am Oszi sehen. Nicht jeder schnellere Impuls wird schön aussehen?
Hallo Bit Kopierer, hier gibt es einen kostenpflichtigen c't-Artikel zum Thema "Bitfäule" in epischer Breite: https://shop.heise.de/archiv/search/result?query=bitf%C3%A4ule
:
Bearbeitet durch User
unter Win7 kommt es ausserdem bei falscher Einstellung "gerne" immer zu diesem elendigen Ladebalken. Dann rödelt die Festplatte bei Multimedia-Geschichten rum wie blöde. Abhilfe dazu hier: Beitrag "Windows Explorer ewiger grüner Balken, Lösung"
● J-A V. schrieb: > ausserdem würde der Virenscanner bei jeder Datei > immer erst noch gerne prüfen wollen, was damit los ist... > kann man natürlich auch zum Anlass nehmen, > das endlich mal zu checken :D ja, dann sind bei 1TB Daten 3 Dateien dabei die ins Virenmuster passen und werden in Quarantäne verschoben oder gelöscht.. dann war es das mit 1:1 Kopie.. nee sind ja dann auf beiden HDDs gelöscht verstehe nur nicht was die Diskussion über die rudimentäte Schnittstelle SATA oder auch USB bringt. Das ist doch völlig egal, wichtig ist doch nur dass das verwendete Tool sicherstellt das die Daten nach dem kopieren exakt gleich sind, selbst wenn das Tool es 1Mio mal versuchen muss zu kopieren Danke, dass es auch noch andere hier gibt, die in Zeiten von bunten Bilder Soft auch noch die Konsolenprogramme nutzen.
Nochmals der Tip Richtung Robocopy, mit den richtigen Schaltern haben wir damit viele Terabyte Fileserver übertragen. Der einzige Haken unter Windows ist, dass zu lange Pfad- und Dateinamen dabei richtig Scheiße produzieren können, dazu hatten wir mal nen robocopy "Trockenlauf" laufen lassen, der die Problematischen Fälle erstmal rausfiltert und auflistet. Nur so als Tipp, falls das in Deinem Szenario vorkommen könnte. (Eine Gewisse Abteilung hatte immer halbe Romane mitsamt Sonderzeichenzoo in Pfad und Dateinamen geschrieben, die Honks) Man kann Robocopy so einsetzen, dass man erstmal einzelne Brocken z.B. oberste Verzeichnisordner wegsichert und dann das in der Zwischenzeit aufgetretene Delta als reine Differenzsicherung nachzieht. Ich hab die richtigen Parameter nicht mehr im Kopf, aber das Goorakel wird helfen ;-) Gruß
Aus persönlicher Erfahrung kann ich berichten daß mir bislang nur genau ein einziges Mal in den letzten 35 Jahren Daten beim Umkopieren kaputtgegangen sind - und dann gleich gründlich mehrere Terabyte - und das ließ sich dann recht schnell ursächlich auf defektes RAM im betreffenden Rechner zurückführen. Überall unterwegs und auf der Platte sind die Daten mit CRC abgesichert, nur nicht während der kurzen Zeit in der die nackten Daten ohne weitere Verpackung im Speicher herumliegen und darauf warten wieder geschrieben zu werden. ECC-RAM soll hilfreich sein, sagt man.
:
Bearbeitet durch User
Jörch B. schrieb: > Der einzige Haken unter Windows ist, dass zu lange Pfad- und Dateinamen > dabei richtig Scheiße produzieren können, dazu hatten wir mal nen > robocopy "Trockenlauf" laufen lassen, der die Problematischen Fälle > erstmal rausfiltert und auflistet. Nur so als Tipp, falls das in Deinem > Szenario vorkommen könnte. Achtung, es gibt mehrere Versionen vom Robocopy, XP010 war bis XP gedacht, läuft stabil und schnell hat aber die Probs mit allzu langen Pfaden, kommt aus dem Resourcekit XP026 war dann wohl schon bei Vista dabei und hat die Probs nicht, ist aber etwas langsamer > Ich hab die richtigen Parameter nicht mehr im Kopf, aber das Goorakel > wird helfen ;-) die über 70 Parameter muss man nicht im Kopf haben wichtig ist doch wohl, das nach dem abeschlossenen Kopiervorgang, dieser nochmals angestoßen wird, das Programm dann alle Dateien prüft und sollte beim Kopieren ein Fehler aufgetreten sein, dieser behoben wird. Erst nach einem komplett erfolgtem kopieren kann man feststellen ob sich vielleicht in der Verzeichnisstruktur ein Fehler eingeschlichen hat
Thomas S. schrieb: > vielleicht in der Verzeichnisstruktur ein Fehler eingeschlichen hat Genau da ist der wunde Punkt, wenn die Rechte nicht reichen oder komische Datei$nam§en Ärger machen. Deswegen wäre mir ein 1:1 Image lieber als 1000 einzelne Dateinamen mit Problemen. Das heißt aber nicht, daß RAM-Fehler oder andere HW-Probleme noch "viel Spaß" machen könnten. Durch Fehler wird man klüger.
oszi40 schrieb: > Deswegen wäre mir ein 1:1 Image > lieber als 1000 einzelne Dateinamen mit Problemen. Ich kaufe mir in bestimmten Abständen für meinen Laptop eine neue HDD/SSD und clone diese in einer externen Dockingstation mit Clonefunktion, die macht eigenständig ohne PC/Windows eine 1:1 Kopie, die ich dann in meinem Laptop verwende. Die "alte" HDD lege ich in den Schrank und habe für den Notfall eine voll lauffähige HDD mit Stand vom xx.xx.xxxx, damit fahre ich recht gut.
>> Ja wir hams ja begriffen... Dein Tool will halt einfach keiner. Robocopy ist imo erste Sahne. Nur weil man sich den Kindergarten hier passiv reinzieht und nicht gleich damit hausieren geht bedeutet das noch lange nicht das es keiner will. > > Woran man sehr schön sehen kann, wie dumm doch die Welt ist. Denn das > Tool bietet alle nur denkbaren Vorteile: Aber es ist halt Kommandozeile und man kann eine Menge Unfug damit anstellen. Oder andersrum, wer damit umgehen kann kennt es sowieso. Thomas S. schrieb: > Erst nach einem komplett erfolgtem kopieren kann man feststellen ob sich > vielleicht in der Verzeichnisstruktur ein Fehler eingeschlichen hat Meiner einer überträgt Daten komprimiert. Theorie dahinter ist, dass dann Übertragungsfehler herausfallen und man die Integrität auf einer höheren Ebene prüfen kann. was haltet ihr von dem Ansatz? Im Widerspruch dazu nehme ich dann zip obwohl man das schlechter reparieren kann wie z.B. tar.
Bernd K. schrieb: > und > das ließ sich dann recht schnell ursächlich auf defektes RAM im > betreffenden Rechner zurückführen. Das ist mir auch mal passiert. Windows lief im 1. Speicherriegel einwandfrei. Als Cache hat es aber den 2. Riegel genommen und der war defekt. Nach einer größeren Aufräumaktion waren dann alle Dateien geschreddert.
HyperMario schrieb: > Meiner einer überträgt Daten komprimiert. Theorie dahinter ist, dass > dann Übertragungsfehler herausfallen und man die Integrität auf einer > höheren Ebene prüfen kann. > > was haltet ihr von dem Ansatz? Nehmen wir mal an du hättest dieses Kommentar hier als Textdatei gespeichert. Wenn du die jetzt kopierst und dabei aus welchem Gründen auch immer, z.B. defektes RAM, ein Fehler auftreten würde. Dann wird halt bspw. aus dem Wort Kommentar das Wort "Kom§entar". Ein Fehler, der zwar stört, aber von den Auswirkungen keine große Rolle spielt. Hast du stattdessen die Datei gepackt, dann kommt es darauf an, welche Einstellung du beim Packen verwendet hast, also mit Fehlerkorrektur oder ohne. Im schlimmsten Fall kannst du dann die gesamte Datei nicht mehr entpacken. Und die Integrität hilft dir dann lediglich zu sagen, dass die Datei kaputt ist, nicht aber genau wo. Das gilt zumindest dann, wenn ohne Fehlerkorrekturmöglichkeit komprimiert wurde. Die Erfahrung hatte ich jedenfalls mal früher mit den Disketten machen müssen. Aus Platzmangel habe ich die Daten gepackt und als ich darauf irgendwann mal wieder zugreifen wollte, war die Datei nicht mehr lesbar und entpackbar, da kaputt. Eine nicht gepackte Datei wäre wie oben gezeigt zwar auch fehlerhaft gewesen, aber der Text wäre noch lesbar gewesen. Wenn man also komprimiert, dann sollte man darauf achten, dass man eine Kompression mit der Möglichkeit einer Fehlerkorrektur verwendet.
Nano schrieb: > Wenn man also komprimiert, dann sollte man darauf achten, dass man eine > Kompression mit der Möglichkeit einer Fehlerkorrektur verwendet. Das ist sicher richtig. Der Vorteil ist aber da man das Archiv schon vor dem Übertragen prüfen kann. Falls es dann ganz sicher sein soll: Wenn ich das nächste mal Daten kopiere mach ich vorher die Windows Speicherdiagnose und einen Systemintegritätsbericht.
Jörch B. schrieb: > Der einzige Haken unter Windows ist, dass zu lange Pfad- und Dateinamen > dabei richtig Scheiße produzieren können IMO gibts dafür, bzw. daGEGEN, den Schalter "/256". Damit werden überlange Pfad-/Dateinamen ignoriert. Sollte natürlich geloggt werden, um hinterher aufräumen zu können. Oder auch nicht, wegens der gerechten Strafe für User, die das Dateisystem mit Twitter verwechseln.
Robocop schrieb: > Schalter "/256". Damit werden überlange Pfad-/Dateinamen ignoriert. Sollte > natürlich geloggt werden, um hinterher aufräumen zu können. Diese 256 rechnen die aber ab der Wurzel! Wenn dann einige Ordner weiter unten /Land/Stadt/Straße/Hausnummer/Gebäude/Etage//die-Datei_mit_langen_Namen_ der $Straße_im_Hinterhof.docx kommt, wird der Namensraum schon recht knapp. einer schrieb: > Platzmangel habe ich die Daten gepackt Kann man machen, aber der kluge Bauer legte nie alle Eier in einen Korb.
oszi40 schrieb: > Diese 256 rechnen die aber ab der Wurzel! Genau. Das ist ja auch exakt das Problem: Das Win32-API hat "exakt" (nicht wirklich, weil: MAX_PATH=260) diese Beschränkung. NTFS und der Windows-Kernel haben sie nicht. Daraus resultiert das Problem: Der Unterbau kann mehr als der Aufsatz. (das soll bei anderen OS auch vorkommen, harharhar...) Was nun Robocopy betrifft, kann das einerseits bestehende Strukturen ohne Verluste kopieren, auch wenn sie die Grenzen des API verletzen, andererseits aber auch eben diese API-Grenzen sicherstellen. Mehr kann man von einem derartigen Tool nicht verlangen. Es obliegt schlicht dem Anwender, zu entscheiden, was ihm im konkreten Fall wichtiger ist: entweder alles zu kopieren oder die Grenzen des API einzuhalten. So sollte es sein: Alle Macht dem Anwender eines Tools! Wenn der nicht hinreichend kompetent ist: kein Mitleid, er könnte ja einfach LERNEN!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.