Dateidatum beim Kopie auf USB-Stick erhalten

[Nikswieweg]

Hallo,
da ich mich neuerdings zwischen mehreren Laptops bewege, habe ich mich entschlossen meine gesamten eigenen Dateien auf einem USB-Stick (wechselnder Laufwerksbuchstabe) abzuspeichern und zu bearbeiten. Erst nachdem ich schon etliche Dateiänderungen vorgenommen habe, ist mir aufgefallen, dass sämtliche nicht bearbeiteten Dateien, aber auch alle Ordner / Unterordner (Verzeichnisse) das Kopierdatum auf den Stick aufweisen, obwohl ich "Kopiere Datum/Zeit von Verzeichnissen" schon immer und ewig aktiviert habe (nun Vers. 7.5).

Die Nutzung der Suchfunktion mit "Datei + Datum / erhalten / auf Original zurück stellen / Usb-Stick" hat mir nicht wirklich weiter geholfen. Möglicherweise stellt das Kopieren auf einen USB-Stick auch einen Sonderfall dar.

Darum die Fragen:
- - Wie kann ich künftig das Verzeichnis-/Unterverzeichnisdatum beim Kopieren auf einen USB-Stick erhalten?
- Wie kann ich künftig das Dateidatum (letzte Bearbeitung) beim Kopieren auf einen USB-Stick erhalten?
- Besteht eine Chance, sämtliche Dateien auf das letzte Bearbeitungsdatum zurück zu stellen?

Bei Antworten auf die letzte Frage bitte bedenken, dass ich mit den teilweise über die Suchfunktion gefundenen Scripts nicht viel anfangen kann - ich weiß nicht, wo ich sie integrieren soll (langjähriger Nutzer von Total Commander aber in der Beziehung TotalAnfänger).

Es wäre vielleicht eine Anregung, in der nächsten Version eine entsprechende Voreinstellung anzubieten.
Gruß
Nikswieweg

[Horst.Epp]

Ich habe alle meine Daten auf einem NTFS formattierten 8 GB Stick. Das Datum von Files und Verzeichnissen wird beim kopieren immer korrekt beibehalten. Natuerlich aendert sich das Verzeichnisdatum, wenn ich Files darin bearbeite, das macht Windows automatisch.

[karlchen]

Hallo, Nikswieweg.

Kann aus eigener Erfahrung Horst.Epps Worte nur unterstreichen.
Kopiere seit Jahren Dateien von Festplatten auf meine USB-Sticks und von dort wieder auf Festplatten.
Dabei laufen die Festplatten an Windows XP oder Vista Systemen. Meine USB-Sticks sind nur auf FAT32 formatiert.
Beim Hin- und Herkopieren zwischen Festplatte und USB-Stick bleibt das letzte Bearbeitungsdatum der Dateien unverändert. (1)

Das Problem, das du siehst, wird mit an Sicherheit grenzender Wahrscheinlichkeit
+ nicht von Windows selbst verursacht
+ nicht vom Total Commander verursacht

Es wurde schon mal in einigen Threads scheinbar Antivirenprodukte als Auslöser ausgemacht. - Aus eigener Erfahrung kann ich das bisher nicht bestätigen. Die von mir benutzten Produkte tun sowas nicht.

Wie kann ich künftig das Verzeichnis-/Unterverzeichnisdatum beim Kopieren auf einen USB-Stick erhalten?

CopyDirTimeStamp=1 (Konfigurieren => Einstellungen => Kopieren/Löschen => [X] Kopiere Datum/Zeit von Verzeichnissen)

Wie kann ich künftig das Dateidatum (letzte Bearbeitung) beim Kopieren auf einen USB-Stick erhalten?

Das ist die (unveränderliche) Voreinstellung des Total Commanders.

Für die beiden ersten Fragen gilt daher: Ohne zu wissen, welche Software das Problem verursacht, wird es schwierig werden, gezielt Gegenmaßnahmen zu treffen.

Besteht eine Chance, sämtliche Dateien auf das letzte Bearbeitungsdatum zurück zu stellen?

Solange du noch Zugriff hast auf das Quelllaufwerk mit allen Quellverzeichnissen und Quelldateien, könntest du das über "Verzeichnisse synchronisieren" bewerkstelligen. Angenommen links ist das Quell-Laufwerk, rechts das Ziellaufwerk (USB-Stick).
(1) Verzeichnisse synchronisieren => Vergleichen
(2) Sicherstellen dass alle Dateien angezeigt werden (Unter "Anzeigen" sind alle 4 Icons gedrückt)
(3) Mit Strg-A alle Dateien auswählen
(4) Rechsklick mit der Maus
(5) Kopiere Dateieigenschaften von links nach rechts
(6) [x] Zeitstempel (Datum+Zeit), die beiden anderen Optionen nicht.

Es wäre vielleicht eine Anregung, in der nächsten Version eine entsprechende Voreinstellung anzubieten.

Voreinstellung für was? Die Voreinstellung des Total Commanders ist es, beim Kopieren und Verschieben das letzte Änderungsdatum von Dateien beizubehalten.

Der Total Commander kann kaum ein Problem verhindern, das durch eine andere (noch unbekannte) Software in deiner Windows Umgebung verursacht wird.

Grüße
Karl
--
(1)
Die kleinen Hakeleien im Sekundenbereich, die sich zwischen NTFS und FAT32 ergeben (können) sind mir bekannt. Die Konsequenzen daraus, dass NTFS Zeiten in Normalzeit ablegt, FAT32 aber in Sommer- oder Normalzeit der aktuellen Zeitzone, ebenfalls. (1hourdif=1)

[ghisler(Author)]

Manyche Virenscanner können das bewirken. Sowohl bei der Systemfunktion CopyFileEx als auch bei meinen eigenen Kopierfunktionen wird das Datum der Datei nach dem Kopieren des Dateiinhalts kopiert. Wenn nun der Scanner die Datei zum Scannen blockiert, kann es sein, dass das Datum nicht gesetzt werden kann.

Mit der Funktion "Verzeichnisse synchonisieren" lässt sich ab TC 7.50 nur das Datum nachträglich kopieren (via Rechtsklickmenü).

[Nikswieweg]

Zunächst einmal vielen Dank für die prompten Antworten!

Immerhin habe ich mit deren Hilfe und ein wenig zusätzlicher Detektivarbeit das Plugin DirSizeCalc.wdx als indirekten Täter entlarvt. Ich habe zum ersten Mal damit gearbeitet und relativ blind die Vorlage unter: http://www.ghisler.ch/wikide/index.php/Verzeichnisgr%C3%B6sse_in_der_Dateiliste übernommen, inkl. [=tc.Erstelldatum]. Das habe ich nun in [=tc.Änderungsdatum] geändert und siehe da ... alles im grünen Bereich, alles wie gehabt. Uff, da gingen dann schlagartig alle Adrenalinschübe runter.

In jedem Fall ist das Plugin für mich sehr wertvoll. Ich denke auch, dass ich künftig mit weiteren dieser Art verstärkt arbeiten werde (habe da en passant noch was von Bilder-, mp3-Plugins etc. gelesen).

Erstaunlich, dass ich nach so vielen Jahren (Win)TotalCommanderAnwendung erst jetzt die ersten Schleier der vielfältigen Möglichkeiten lüfte. Ich ahnte gar nicht, dass man noch so viel "schrauben" kann: Wie das Registry.wfx. Bin mal gespannt, wie ich das ans Laufen bekomme und was es kann.

So wird der TC für mich noch unentbehrlicher, als er eh schon ist.

Gruß und nochmals danke
Nik

[Lefteous]

2Nikswieweg

Immerhin habe ich mit deren Hilfe und ein wenig zusätzlicher Detektivarbeit das Plugin DirSizeCalc.wdx als indirekten Täter entlarvt. Ich habe zum ersten Mal damit gearbeitet und relativ blind die Vorlage unter: http://www.ghisler.ch/wikide/index.php/Verzeichnisgr%C3%B6sse_in_der_Dateiliste übernommen, inkl. [=tc.Erstelldatum]. Das habe ich nun in [=tc.Änderungsdatum] geändert und siehe da ... alles im grünen Bereich, alles wie gehabt. Uff, da gingen dann schlagartig alle Adrenalinschübe runter.

Das verstehe ich nicht ganz. Hast du nur [=tc.Erstelldatum] nach [=tc.Änderungsdatum] geändert oder auch die ganzen dirsizecalc Felder gelöscht?
Wenn es hier ein Problem bin ich gerne bereit mir das mal anzuschauen, aber ein wenig konkreter muss es schon sein. Welche Version setzt du denn ein? Allerdings ist mir im Augenblick schleierhaft inwiefern das Plugin das Setzen von Daten verhindern sollte.

[karlchen]

Hi, Lefteous.

Nikswieweg hat in den Dateilisten die Spalte "Datum" mit [=tc.Erstelldatum] statt mit [=tc.Änderungsdatum] gefüllt.

Da beim Kopieren von Laufwerk A nach Laufwerk B, wenn die Zieldateien auf B noch überhaupt nicht vorhanden waren, diese dort neu erstellt werden, ist auf Laufwerk B [=tc.Erstelldatum] immer der Kopierzeitpunkt.

[=tc.Änderungsdatum] hingegen sind auf aufwerk A und B gleich (auch) nach dem Kopieren.

Wenn Nikswieweg sich nun unwissentlich für Laufwerk A und B jeweils das [=tc.Erstelldatum] hat anzeigen lassen, mußten die voneinander abweichen.

Dein Plugin hat dabei gar nichts falsch gemacht und auch nichts verhindert. Vielmehr ist Nikswieweg erst durch dein Plugin dazu gekommen, überhaupt benutzerdefinierte Spalten zu verwenden und ist dabei in die Falle zwischen [=tc.Erstelldatum] und [=tc.Änderungsdatum] getappt. Auslöser dieses Mißgriffs war die genannte TC Wiki Seite. Dort taucht in einem Screenshot eine Spalte auf, die mit [=tc.Erstelldatum] bestückt ist, nicht mit [=tc.Änderungsdatum].

Grüße,
Karl

[Nikswieweg]

...
Dein Plugin hat dabei gar nichts falsch gemacht und auch nichts verhindert. Vielmehr ist Nikswieweg erst durch dein Plugin dazu gekommen, überhaupt benutzerdefinierte Spalten zu verwenden und ist dabei in die Falle zwischen [=tc.Erstelldatum] und [=tc.Änderungsdatum] getappt. Auslöser dieses Mißgriffs war die genannte TC Wiki Seite. Dort taucht in einem Screenshot eine Spalte auf, die mit [=tc.Erstelldatum] bestückt ist, nicht mit [=tc.Änderungsdatum].
...

Exakt Karlchen, allerdings hätte ICH es nicht so gut formulieren können.

In dem Zusammenhang: Vielen Dank Lefteous, dein Plugin ist für mich Gold wert!
Zusatzfrage: Wieso kann man die Spalte Erweiterung nicht löschen?

[ChrisHH]

Manche Virenscanner können das bewirken. Sowohl bei der Systemfunktion CopyFileEx als auch bei meinen eigenen Kopierfunktionen wird das Datum der Datei nach dem Kopieren des Dateiinhalts kopiert. Wenn nun der Scanner die Datei zum Scannen blockiert, kann es sein, dass das Datum nicht gesetzt werden kann.

Mit der Funktion "Verzeichnisse synchonisieren" lässt sich ab TC 7.50 nur das Datum nachträglich kopieren (via Rechtsklickmenü).

Der Fehler scheint jetzt bei Avira aufzutreten. Nach Kopieren eines USB-Laufwerks auf ein Anderes werden einige Dateien immer mit aktuellem Kopierdatum versehen. Wenn ich den Scanner ausschalte gehts zumindest im normalen Fenster wieder. Beim Verzeichnisse synchronisieren habe ich das Problem allerdings immer noch, auch bei deaktiviertem Avira.
Gibts inzwischen vielleicht aktuellere Tipps wie man das Problem umgeht? 2x einen Dateiabgleich machen ist bei 800Gig recht zeitaufwendig.

Danke, Chris

[MC]

Sind die Platten beide FAT und/oder NTFS? Ist eine davon in der Winterzeit gefüllt worden?

Avira macht bei mir sowas nicht. Aber Probleme durch unterschiedliche Zeitzonen kenne ich zur Genüge, da ist oft FAT32 als Übertragungsmedium die beste Wahl, weil es keine Zeitzonen kennt.

[ChrisHH]

Sind die Platten beide FAT und/oder NTFS? Ist eine davon in der Winterzeit gefüllt worden?

gleiche Platte, anderer Ordner hab ich auch schon getestet. Scheint wirklich an der neuesten Avira-Version zu liegen. Wie gesagt, nach Deaktivierung geht es von der Kommandozeile. Warum der Fehler dann bei "Verzeichnisse synchronisieren" trotzdem noch auftritt kann ich damit allerdings nicht erklären.

Probier mal selber mit disk2vhd.exe und disk2vhd.chm in der neuesten Version von Marc Russionvic, die beiden Dateien provozieren das zum Beispiel. Im 7zip-Ordner waren es auch mehrere Dateien.
Avira-Produktversion 14.0.7.342 23.10.2014
Suchengine 8.03.26.26 26.11.2014
Virendefinitionsdatei 8.11.189.146 29.11.2014

VG
Chris

[MC]

Gleiches Avira, gleiche Dateien: ausgepackt, Solo als auch mit anderen zusammen zwischen verschiedenen Platten hin und her kopiert: immer exakt identisch.

Dass der Fehler bei der Sync-Funktion auch ohne Avira auftritt beweist IMHO, dass er von einem anderen Hintergrundwasauchimmer ausgelöst wird.