jpg-Datum u. -Größe verändern sich manchmal beim Verschieben

[Babbo]

Ich begrüße euch alle, hier wieder einmal ein forums-newbie-beitrag …

Vorneweg: Ich habe die Suchfunktion ausgenützt, zwar – wirklich! - viele Hinweise, aber nie was letztlich Hilfreiches gefunden, also erlaube ich mir einen neuen Beitrag zu eröffnen …

PC: Win 7, 64bit, alles up-to-date, hab keine Probleme, Total Commander 8.0

Ausgangslage: Meine jpgs hole ich mir mittels vom Kamerahersteller mitgelieferter Software auf die Festplatte. Dort werden sie mir mit dem Dateidatum abgespeichert, das der EXIF-Info entspricht. TC zeigt das auch so an, nämlich so wie ich es möchte: Dateidatum ist gleich Aufnahmedatum.

Ab und zu verschiebe ich auch mal jpgs in ein anderes directory und dann passiert hin und wieder folgendes:

1) Das Datum (inkl. Zeit) des verschobenen jpgs wird im Ziel-folder auf das „Verschiebe-Datum“ gesetzt …

2) … und – kurios, aber wahr – unter Umständen verringert sich auch die Dateigröße (gegenüber dem Original, das auch noch in einem anderen Sicherheits-folder lagert)!

Wie erwähnt, 1) kann passieren, passiert aber nicht immer, und wird auch nicht immer von 2) begleitet. Klingt alles recht unwahrscheinlich, ist aber genau so. Ich hab endlose und leider auch erfolglose Sessions hinter mir, in denen ich systematisch versucht habe, den Fehler exakt zu reproduzieren. Darauf gibt’s nur zwei Antworten. Entweder ich bin zu einfältig um die Systematik zu erkennen oder es ist tatsächlich der (so genannte) Zufall im Spiel.

Noch ein paar Anmerkungen:

* Mir geht’s nicht um’s folder-Datum, NTFS ändert hier eben laufend mit, damit kann ich leben. Aber ich will eben nicht mein Aufnahmedatum aus den jpg-metadaten herauskitzeln müssen (sondern hätte es halt auch nach dem Verschieben gerne im Dateidatum, das der TC anzeigt, manifestiert).

* Dass hier nichts von Kopieren steht hat den Grund, dass mir dieses „Fehlverhalten“ bisher eben immer nur beim Verschieben aufgefallen ist.

* Was die unterschiedliche Größe betrifft, ist mir bei der Bildbetrachtung und in den Metadaten kein Unterschied aufgefallen, wohl aber bei TCs Binärvergleich zweier solcher unterschiedlich großer jpgs.

Vielen Dank für jeden zweckdienlichen Hinweis und jedenfalls noch einen schönen Abend!

[Dalai]

Virenscanner funken gerne mal dazwischen, wenn Dateien gelesen/geschrieben werden. TC kann das Datum einer Datei natürlich nur setzen, wenn er sie fertig geschrieben hat. Wenn der Scanner aber nicht vor diesem Zeitpunkt mit seiner Arbeit fertig ist, kann der TC keinen Zeitstempel setzen und dieser bleibt somit unverändert der Erstellzeitpunkt (Kopier-/Verschiebezeitpunkt).

Ich halte es für möglich, dass das auch die Größenänderung auslöst oder gar verursacht, andererseits gibt's da noch weitere Möglichkeiten: Dateisystemfehler, Hardwaredefekte, Treiberprobleme usw.

MfG Dalai

[Babbo]

Danke & Du meinst also TC und Windows sind mit dem Schreiben früher fertig als der Scanner mit seiner Überprüfung ... soll heißen, das Datum kann erst nach Fertigstellen der Überprüfung gesetzt werden? Aber warum wird denn nicht auch nach Fertigstellung der Überprüfung, das alte ("richtige") Datum beibehalten und geschrieben?

Was deinen 2. Absatz betrifft, wüßte ich nicht was falsch sein sollte. Absolut alles andere (MS-Office, Internet, FTP, Programmierumgebungen, Bild, Video usw. usf.) funktioniert tadellos im (fast) Dauerbetrieb!

[Dalai]

Aber warum wird denn nicht auch nach Fertigstellung der Überprüfung, das alte ("richtige") Datum beibehalten und geschrieben?

Wer sollte es denn setzen? Der Virenscanner weiß von dem Zeitstempel der Quelldatei nichts. Und TC kann nicht wissen, wann der Scanner mit seiner Arbeit fertig ist.

Um es mal etwas näher zu erläutern, wie ein Verschieben in Einzelschritten funktioniert:

1. Es wird eine neue (leere) Datei im Ziel angelegt. Zeitstempel: aktuelle Zeit
2. Es wird in Blöcken die Quelldatei in die Zieldatei kopiert. Zeitstempel: weiterhin aktuelle Zeit. Das ist übrigens auch der Grund, warum bei einem länger andauernden Download der Zeitstempel "mitläuft".
3. Es wird die Zieldatei geschlossen. Zeitstempel: immer noch aktuelle Zeit.
4. Es wird der Zeitstempel der Zieldatei auf den der Quelldatei gesetzt.
5. Es wird die Quelldatei gelöscht.

So sieht - ein bisschen vereinfacht - der Idealfall aus. Ein Virenscanner hängt sich nun zwischen Schritt 3 und 4 rein, so dass Schritt 4 im dümmsten Fall gar nicht mehr erfolgreich ausgeführt wird. Das liegt einfach daran, dass ein Virenscanner eine Datei ebenfalls öffnen kann und AFAIK können bei offenen Dateien keine Zeitstempel gesetzt werden, die nach dem Schließen der Datei (durch den Scanner) auch erhalten bleiben.

Um nun der Ursache auf die Spur zu kommen, solltest du einfach testweise den Scanner deaktivieren und dann die Kopier-/Verschiebevorgänge wiederholen, um zu prüfen, ob's ohne Scanner auch auftritt.

MfG Dalai

[Babbo]

Danke Dalai für deine detaillierten Erklärungen!

Habe neue Verschiebungen getestet. Und zwar so: 5 mal die selben 200 jpgs, in 5 separate dirs kopiert. Von diesen 5 dirs dann (die dort umbenannten jpgs) in ein Zieldir verschoben. Dort landeten nunmehr also 1000 jpgs mit in Summe mehr als 4GB. Fehlerfrei! Dann die 1000 ein weiteres Mal in ein neues dir verschoben ... wieder fehlerfrei .... Abschließend dann ein ca. 2GB großes Rar-Archiv (aus 4 Teilen) entpackt und währenddessen die 1000 wieder in das alte dir zurück verschoben ... fehlerfrei ...!

Und alles während mein Avast (Ver.8.0.1489, Freeware) im Hintergrund mit - wie schon immer - aktiviertem Dateischutz lief.

Ziemlich verrückt die Geschichte, weil ich mich nur zu gut an die Handvoll jpgs (ca. 50-70) erinnere, die ich erst unlängst verschoben hatte, wo dann gut die Hälfte mit dem richtigen und der Rest mit falschem Datum ankam

Auch geben alle diese - leider bislang sinnlosen - Tests keinen einzigen Anhaltspunkt ab, der irgendwie auch nur entfernt jene unterschiedlichen Dateigrößen zweier "an und für sich" identischen jpgs erklären könnte.

Ich habe nicht die geringste Idee, wie man hier weiter kommen könnte.

[HolgerK]

- Wohin wird denn verschoben?
(Auf dem gleichen/ein anderes Laufwerk, Netzwerk, externe USB-Platte/Stick, ...)

- Welche Kopiermethode ist denn im TC aktiv?
(Konfigurieren->Einstellungen->Optionen..: Kopieren/Löschen)

Evtl. hilft es ja die

Standard-Kopiermethode benutzen (empfohlen)
Überlässt Total Commander die Wahl der Kopiermethode. Zurzeit ist das die interne Standardmethode via ReadFile/Writefile unter Windows 9x/ME, und die Funktion CopyFileEx unter Windows NT/2000/XP/Vista/7.

oder den

Kompatibilitätsmodus für folgende Laufwerke verwenden:
Der Kompatibilitätsmodus eignet sich für spezielle Laufwerke, die mit den Standardmethoden Probleme haben, z.B. USB-Speichersticks. Geben Sie hier einfach die gewünschten Laufwerksbuchstaben und/oder \ für die Netzwerkumgebung an, oder * für alle. Dieser Modus steht nicht unter Windows 9x/ME zur Verfügung. Er verwendet die Windows-Funktion CopyFileEx.

zu aktivieren?

Von diesen 5 dirs dann (die dort umbenannten jpgs) in ein Zieldir verschoben

Ist das dein Standard-Use-Case?
Nicht doch einmal, im Eifer des Gefechts, eine Reihe namensgleicher aber unterschiedlicher Dateien im Zielverzeichnis überschrieben?

Gruss
Holger

[Babbo]

Ein Dankeschön auch an HolgerK - hier meine Antworten:

Alles spielt sich auf derselben Arbeits-HDD ab, genauer auf einer 1TB großen Partition einer 2TB WD-HDD (das System ist auf einer Samsung 830er SSD mit 256GB).

Die Kopiermethodeneinstellungen hab ich beim TC noch nie berührt ..., die Einstellungen sind daher default bei mir mit "Standard-Kopiermethode benutzen (empfohlen)" angehakt.

Den Kompatibilitätsmodus - lt. Hilfe für USB-sticks - habe ich noch nie ausprobiert (hatte seit geschätzten mehr als eineinhalb Jahrzehnten mit dem TC(WC) auch noch nie nur ein einziges Problemchen ...).

Dass ich von 5 dirs in Summe 1000 jpgs in ein Zieldir rumschiebe und dort wieder mal die 1000 in ein anderes und zurück verschiebe (noch dazu während Winrar werkelt) ist natürlich nicht mein Standard-case, das war nur ein Stresstest, der leider negativ verlief (und damit nichts zur Problemeinkreisung beitrug), weil die obigen beiden Fehler auch kein einziges Mal wieder aufgetreten sind. Die Probleme traten bei "ganz normalen" Datenmengen auf, etwa 20, 30, 40 jpgs á 3, 4, 5 GB verschieben.

Was den Eifer des Gefechts betrifft: Klar, alle vor einem PC machen Fehler, so auch ich - aber nicht jetzt ... mein Grundproblem lautet nach wie vor noch "Beim Verschieben von jpgs mit dem TC wird manchmal das Dateidatum mit dem Verschiebedatum überschrieben und manchmal wird die Zieldatei zusätzlich auch kleiner".

Ich werd' weiter drauf achten und hoffen, dass wieder einmal was reproduzierbar Falsches rauskommt. Bisher habe ich den Fehler zwar oft "genug" erlebt, aber jedes Mal, wenn ich dachte, jetzt habe ich die Systematik, taucht der Fehler in Zukunft unter den verdächtigen Umständen nicht mehr auf oder passiert dann plötzlich wieder unerwartet ...

[Babbo]

Gerade eben wieder!

21 jpgs in einem Ordner, Anlegen eines Unterordners namens "_" und Verschieben (Shift-Maus-Methode) aller Dateien auf einmal in das neue dir.

In "_" kommen alle Dateien an, aber: Nur die ersten 12 behielten ihr Änderungsdatum (=EXIF), die restlichen 9 bekommen das (jetzige) Verschiebedatum. Die mit dem neuen Datum sind alle kleiner als ein backup der Originale, ein Unterschied ist im Bildbetrachter nicht zu erkennen.

Edit: Hab die EXIFs zweier unterschiedlich großer Dateien ein und desselben jpgs verglichen (nach copy to clippboard in zwei Textdateien) und ...:

* Das richtige, größere enthält mehr Infos
* alle Offset-Werte sind verschieden: ExifOffset, InteroperabilityOffset, JpegIFOffset und auch der JpegIFByteCount (sagt mir leider nicht wirklich viel)
* Im Bildbetrachter ist kein Unterschied sichtbar

[HolgerK]

Das hört sich allerdings nicht nach einem Kopierfehler an sondern eher nach einer Bildverarbeitung...

... und Verschieben (Shift-Maus-Methode) aller Dateien auf einmal in das neue dir.

Nur mal so angenommen ein Drag&Drop Handler von einem Bildbearbeitungsprogramm ist im System installiert(*).

- Welche Mausmodus ist im TC eingestellt "Konfigurieren->Einstellungen..:Operation: Markieren mit der Maus" ?

- Mit welcher Maustaste führst du Drag&Drop aus?

- Öffnet sich da evtl. beim Loslassen der rechten Taste ein Kontextmenu aus dem du "Verschieben" auswählst?

- Gibt es evtl. in diesem Menü noch andere Einträge die auf eine Bildbearbeitungsfunktion hinweisen (Verkleinern)?

(*) Mit shellexView kann man kontrollieren welche Drag&Drop Handler(nach Spalte Type sortieren) im System von welchem Hersteller installiert sind, und diese bei Bedarf abschalten.

Gruß
Holger

[Babbo]

Ob ein Drag&Drop Handler im System istalliert ist/wurde, weiß ich nicht, aber ich werd mal versuchen mit Hilfe deines Programmes schlau zu werden ...

TC-Mausmodus: "Rechte Maustaste wie unter Dos", das bedeutet für mich langer rechter Klick (auf eine beliebige Datei) und das Window-Kontextmenü öffnet sich (damit arbeite ich aber nie beim Kopieren und Verschieben) und kurzer rechter Klick zum Markieren.

D&D-Verschieben mach ich so: Ctrl.-A (für alle markieren), linke Maustaste auf den markierten Dateien gedrückt halten, gleichzeitig Shift drücken, die Maus ins Zielverzeichnis ziehen, dann linke Maus freigeben.

Es öffnet sich kein Kontextmenü (warum sollte sich auch eins öffnen, ich mache D&D ja nur mit der linken Maustaste ...)

Kein Menü, keine wie immer gearteten Bildbearbeitungseinträge.

So, das war's, ich mach mich an's shellexView'n ...

[HolgerK]

Ach noch zwei nervige Fragen:
- Ist da evtl. ein virtueller Folder wie \\Desktop als Quelle beteiligt?
- Wenn die Betätigung beim Drag&Drop "Einstellungen: Diverses" nicht ausgeschaltet ist, wie sieht der Bestätigungsdialog aus?

Apropos:
- Verschieben geht auch mit gedrückter Alt-Taste anstelle von Shift.
- oder mit linker Maustaste Ziehen und vor dem Loslassen der linken Taste die rechte Maustaste gedrückt halten.
Nur mal so als Vorschlag falls Shift irgendein modifiziertes Kopierverhalten des Systems antriggert.

Gruss
Holger

[Babbo]

Nerven ist gut - du hilfst mir ja!

* Nein nix Virtuelles, nur ein einfaches (z.B.) d:\Photo\2013 10 12\, von dem in ein d:\Photo\2013 10 12\_\ verschoben wurde
* Die Bestätigung ist ausgeschaltet, daher gibt's auch keinen Dialog
* Jene beiden alternativen Verschiebemethoden hab' ich noch nicht ausprobiert (so schwer reproduzierbar der Fehler eben ist ...)

shellexView: Habe 275 Einträge und an die 20, 30 mit dem Suchwort "handler" gesichtet. Hier scheint nichts Verdächtiges auf, aber ... wirklich beurteilen kann ich das nicht.

Neue Denkansätze:

* Kann man auf Grund zweier unterschiedlich großer solcher jpgs vielleicht etwas mehr aussagen, wenn sie jemand ansieht, der mehr davon versteht als ich (TC's Vergleichstool zeigt mir ja die Unterschiede ..., aber sagt mir natürlich nicht warum sie entstanden sind (Das wär doch mal ein cooler Verbesserungsvorschlag für den TC^^)

* Was kann 9 von 21 Dateien während eines Kopiervorgangs verändern ...?

* Warum ist Bildbetrachtungs-mäßig so überhaupt kein Unterschied feststellbar ... trotz doch beträchtlicher Größenunterschiede?

* 9 von 21 klingt irgendwie nach cache-Problemen ... aber wenn ich 1000 während eines EntRARens problemlos verschieben kann ...

* ... hängt's vielleicht eher mit dem Ursprung des Materials zusammen (wobei ich hier gleich anmerken kann, dass alle betroffenen jpgs von ein und der selben Kamera stammen) ...

[ZoSTeR]

Mit dem Process Monitor sollte sich schnell klären lassen welcher Prozess da eingreift.

[Babbo]

Danke ZoSTeR ..., aber ich vermag die Einträge leider nicht zu deuten, auch wenn mir klar ist, dass dieses tool im Fall des Falles tatsächlich protokolliert was geschah. Auch bin ich von der schieren Menge der Info überwältigt (geschätzte 500-1000 Einträge pro Sekunde). Hier müsste man dann wohl sinnige Filter setzen, aber das übersteigt meinen Horizont

[HolgerK]

d:\Photo\2013 10 12\, von dem in ein d:\Photo\2013 10 12\_\

Das ist in der Regel eine einfache Umbenennung, bei der die Daten nicht angepackt werden sondern nur der Verzeichniseintrag verschoben wird.

Es könnte natürlich sein, dass just in dem Moment, in dem TC diese Operation durchführt, ein anderes Programm einen blockerenden Zugriff auf die Datei hat.
Dann würde TC die Datei-Daten wirklich kopieren und im Anschluss daran versuchen die Quelldatei zu löschen.

Das reine Umbenennen ist so schnell, dass man bei wenigen Dateien kaum mitbekommt das ein Progressdialog aufpoppt.
Beim Kopieren sollte dieser Dialog allerdings kurz sichtbar sein.

Schalte doch mal unter "Konfigurieren -> Einstellungen..: Log-Datei" alle Optionen ein.
Falls das Problem noch mal auftritt, dann sollte in der Log-Datei dort anstelle einer Reihe von Einträgen wie:

Code: Select all

DATUM UHRZEIT: Verschieben: d:\Photo\2013 10 12\NAME.jpg -> d:\Photo\2013 10 12\_\NAME.jpg

zusätzlich ein Eintrag:

Code: Select all

DATUM UHRZEIT: Löschen: d:\Photo\2013 10 12\NAME.jpg

stehen.
Falls "Löschen" dort nicht auftaucht, dann waren die Daten im Quellverzeichnis bereits geändert, oder du vergleichst nicht mit der originalen Quelle.

Mögliche Ursachen für ein solches Kopieren/Löschen anstelle von schnellem Umbenennen können Virenscanner oder Shell-Erweiterungen wie Tooltips oder Thumbnail-Extractor sein.

BTW: welche Ansicht benutzt du: "Miniaturansicht"?

Gruss
Holger