Dateiinhalt syncronisieren mittels read/write binary file

Hallo,

ich möchte 2 dateien (quell-und zieldatei) bitweise? auf unterschiede vergleichen und die unterschiede in die zieldatei übernehmen.
der hintergrund ist folgender, wir haben binäre dateien, eine liegt lokal auf einem rechner die andere auf einem server, ich will zur zeitpoptimierung nicht die veraltete datei durch die neue veränderte datei ersetzen, sondern nur die unterschiede rausfinden und diese schreiben. ich habe bereits so ein programm geschrieben, aber der benötigte zeitaufwand war größer als ein einfaches kopieren der datei, was eigentlich ja nicht nachvollziehbar ist.
ich habe 2 varianten versucht, zum einen das jedes bit der zieldatei mit dem der quelldatei verglichen wird und nur die unterschiede überschrieben werden, und die andere variante hat letztendlich den unterschiedl. inhalt der beiden dateien an den inhalt der zeildatei angehängt . beide varianten sind extrem langsam, viellt könnt ihr mir weiterhelfen. ausserdem können die dateien bis in den gb bereich gehen.

variante 1 ist für große dateien leider nicht geeignet, aufgrund der speicherauslastung, war auch nur ein test, eigentlich reicht es aus, den differenzinhalt zwischen der größeren und kleineren datei an das ende der kleineren datei anzuhängen. das funktioniert auch aber dauert viel zu lange, sogar bei datein im bereich der 50mb

variante 1:
   

variante 2:
   

würde mich sehr über hilfe freuen

Anzeige

Lies Dir mal die LVF-Regeln durch, vor allem die Punkte mit den externen Links und der Groß- und Kleinschreibung.
Bilder kannst Du im Forum direkt hochladen und Dein Text wird auch lesbarer, wenn Du nicht alles klein schreibst.

Gruß Markus

Entschuldigung, kommt nicht mehr vor.

Hab' jetzt mal die Bilder für Dich hier im Forum hochgeladen und die Links zu "Dropbox" entfernt.

Gruß Markus

(18.07.2013 12:42 )manuwestern schrieb:  Entschuldigung, kommt nicht mehr vor.

Hallo manu,

Zitat:ich will zur zeitpoptimierung nicht die veraltete datei durch die neue veränderte datei ersetzen, sondern nur die unterschiede rausfinden und diese schreiben. ich habe bereits so ein programm geschrieben, aber der benötigte zeitaufwand war größer als ein einfaches kopieren der datei, was eigentlich ja nicht nachvollziehbar ist.

Mal überlegen:
Einfaches Kopieren bedeutet:
- Datei A lesen, Datei B (über)schreiben. Fertig.

Vergleichen und Kopieren bedeutet:
- Datei A lesen, evtl. byteweise
- Datei B lesen, gleiche Blockgröße wie bei Datei A
- beides vergleichen
- Unterschiede finden
- Unterschiede (byteweise?) in Datei B überschreiben, dabei immer schön abwechselnd SetPosition und Write
Zusammengefasst zu: Datei A und B komplett lesen, vergleichen, Datei B stückchenweise überschreiben

Was ist an dem Zeitunterschied nicht nachvollziehbar?

Simple Lösung: Dateiinfos (Zeitstempel) vergleichen und danach entscheiden, welche Datei neu ist und was nicht.
Simple Lösung 2: RoboCopy oder FreeFileSync oder Software xyz einsetzen - die sind auf sowas spezialisiert...

Sry, hätte mir mehr Gedanken bei der Formulierung machen sollen.

Der Punkt ist folgender, die Dateien liegen im GB-Bereich. Es geht um Postfächer, die über die Jahre mehrere GB Emails angesammelt haben und nun auf dem Server gesichtert sind, da jetzt tagtäglich neue Emails hinzukommen, der Dateigrößenunterschied dann jedoch nur noch wenige MB beträgt, wäre es sinnvoller nur die Änderungen zu übernehmen anstatt den vorhanden Inhalt mit zu kopieren.
Ich weiß, dass es spezielle Programme gibt, trotztdem hat mich Umsetzung mal interessiert. Ich kann mir trotzdem nicht erklären, warum das Anhängen eine Inhalts solange dauert, ausserdem hätte ich vermutet, dass der Vergleich zweier Bits zwar Zeit in Anspruch nimmt, aber dennoch schneller ist als das Schreiben/Kopieren in eine Datei.

Ich hatte auch noch andere Varianten, z.B anstatt die Datei im ganzen Auszulesen wie in Variante 2, nur Bit für Bit auszulesen und zu vergleichen, um auch größere Dateien zu handhaben, zwar wird der Speicher nicht mehr überfüllt, aber von der Performance gibt es keinen Vorteil.

Wahrscheinlich fehlt mir auch das Wissen über den genauen Vorgang beim Einlesen/Auslesen von Daten.

Hallo manuwestern,

vielleicht kannst du von der OpenG-Palette das Vi "Compare File Binary" für deine Zwecke anpassen.

Gruß Christian

   

Hallo manu,

Zitat:Der Punkt ist folgender, die Dateien liegen im GB-Bereich ... der Dateigrößenunterschied dann jedoch nur noch wenige MB beträgt, wäre es sinnvoller nur die Änderungen zu übernehmen anstatt den vorhanden Inhalt mit zu kopieren.

Der Punkt ist folgender: kannst du dir sicher sein, dass die Dateien nur am Dateiende unterschiedlich sind?

Ansonsten:
- Größe von Datei A bestimmen
- Größe von Datei B bestimmen
- nur den Teil von Datei A kopieren, der größer als Datei B ist
    (korrekte Optionen beim DateiÖffnen etc. noch einstellen)

Zitat:hätte ich vermutet, dass der Vergleich zweier Bits zwar Zeit in Anspruch nimmt, aber dennoch schneller ist als das Schreiben/Kopieren in eine Datei.

Das Lesen zweier Bytes aus zwei Dateien ist nahezu gleich schnell wie das Lesen eines Bytes aus A und das Schreiben eines Bytes in B. Moderne Betriebssysteme verwenden jede Menge Puffer bei Dateioperationen...

Zitat:Ich hatte auch noch andere Varianten, z.B anstatt die Datei im ganzen Auszulesen wie in Variante 2, nur Bit für Bit auszulesen und zu vergleichen, um auch größere Dateien zu handhaben, zwar wird der Speicher nicht mehr überfüllt, aber von der Performance gibt es keinen Vorteil.

Abgesehen davon, dass man wohl kaum GiB-große Dateien am Stück laden und speichern sollte: üblicherweise arbeitet man mit Blockgrößen von 64KiB bis 256KiB. Das passt zu den oben genannten Puffern des OS als auch der meisten Hardware. Die Performance dürfte dann nahezu 100% dem Lesen/Schreiben ganzer Dateien entsprechen... (Siehe auch Christians Hinweis: auch dieses VI verwendet eine "vernünftige" Blockgröße!)

P.S.:
- Wieso liest du ein Array of U8 (=Strings) explizit als little-endian ein?
- Deine Fortschrittsanzeige (ver)braucht auch Zeit...

Okay das Beispiel funktioniert trotzdem nur im Bezug auf "kleine Dateien", es handelt sich aber nun mal leider um große Dateien. Mein VI, davon abgesehen ob es nun verbesserungsfähig ist oder nicht, handhabt auch große Dateien. Gehen wir davon aus, dass sich die Dateien nur am Ende vergrößern/verändern, dann wundert mich trotzdem , warum es verhätlnismäßig lange dauert einen Inhalt an eine Datei anzuhängen im Vergleich dazu die Datei gleich direkt zu kopieren/überschreiben. Sehe ich das falsch?

Das Beispiel 1 meines VIs, ist in der Praxis total träge, obwohl nicht mehr gemacht wird, als ab einen bestimmten Punkt die Daten der größeren Datei an das Ende der kleineren Datei anzuhängen. Wenn ich stattdessen eine 50MB große Datei einfach kopiere geht es schneller, obwohl die zu schreibende/kopierende Datenmenge einfach größer ist.

Ich dachte "Little Endian" müsste man für Windows-System nutzen, weil die Art wie die Daten im Arbeitsspeicher abgelegt und zum Schreiben genutzt werden sonst fehlerhaft verarbeitet werden?!

Ich hatte letztes Semester im ET-Studium LabVIEW, also bin Einsteiger, deshalb bitte nicht wundern, warum meine Programmiertechnik nicht die beste ist.

Danke für die Hilfe schonmal.

Hallo manu,

Zitat:das Beispiel funktioniert trotzdem nur im Bezug auf "kleine Dateien"

Man kann das Lesen/Schreiben der Daten sehr einfach in eine Schleife packen und, wie schon beschrieben, mit vernünftigen Blockgrößen arbeiten...

Zitat:Das Beispiel 1 meines VIs, ist in der Praxis total träge, obwohl nicht mehr gemacht wird, als ab einen bestimmten Punkt die Daten der größeren Datei an das Ende der kleineren Datei anzuhängen. Wenn ich stattdessen eine 50MB große Datei einfach kopiere geht es schneller, obwohl die zu schreibende/kopierende Datenmenge einfach größer ist.

Hatte ich schon einmal den Hinweis auf "vernünftige" Blockgrößen gegeben? Es ist bestimmt langsamer, wenn man 1MB einzeln Byte für Byte von Datei A nach Datei B kopiert als wenn man 25MB mit Blockgrößen von 256KB transferiert (1Mio ggü. 100 Dateizugriffen)...
Glaubst du etwa, andere Programme (wie der Explorer etc.) kopieren Dateien einzeln Byte für Byte?

Zitat:Ich dachte "Little Endian" müsste man für Windows-System nutzen, weil die Art wie die Daten im Arbeitsspeicher abgelegt und zum Schreiben genutzt werden sonst fehlerhaft verarbeitet werden?!

Wie willst du einzelne Bytes (String = Array of U8) irgendwie anders im Speicher ablegen?