Datum beim Kopieren von Verzeichnissen beibehalten

[franc]

Hallo,
ich suche eine Möglichkeit wie ich das Originaldatum eines kopierten (oder verschobenen) Verzeichnisses erhalten kann. Ich habe hier im Forum einen Post von 1903, äh.. 2003 gefunden wo genau dies gesucht wird, allerdings ohne Antwort.
Ist das vielleicht mittlerweile implementiert, oder gibts da eine Möglichkeit?

DasVerzeichnissdatum ist für mich oft ein wichtiges Kriterium, das ich nicht verlieren will beim Verschieben.

Gruss,

franc walter

[Stitscher]

Unter Konfiguration--->Kopieren/Löschen--->Kopiere Datum/Zeit von Verzeichnissen

[franc]

Unter Konfiguration--->Kopieren/Löschen--->Kopiere Datum/Zeit von Verzeichnissen

Das hatte ich schon gesehen und aktiviert.
Tatsächlich wird das Datum bei ganz wenigen Verzeichnissen übernommen, aber die meisten kriegen ein neues Datum.
Ich kann aber keine Gesetzmässigkeit erkennen - seh ich den Wald vor lauter Bäumen nicht ?

[sqa_wizard]

Tatsächlich wird das Datum bei ganz wenigen Verzeichnissen übernommen, aber die meisten kriegen ein neues Datum.

Das ist eine Eigenschaft des Dateisystems (NTFS).
Dieses setzt das Datum des Verzeichnisses auf das aktuelle Datum sobald in diesem Verzeichnis etwas geändert wird.

Wenn du etwas in dieses Verzeichnis kopierst, wird das Datum geändert.

Aus diesem Grund gibt es die Einstellung "Konfiguration--->Kopieren/Löschen--->Kopiere Datum/Zeit von Verzeichnissen"
Nachdem der Kopiervorgang abgeschlossen ist, setzt der TC das Verzeichnisdatum explizit auf den ursprünglichen Wert.

Soweit die Theorie ...

In der Praxis kann es aber Vorkommen, dass das Betriebssystem meldet "Kopiervorgang abgeschlossen" (und TC entsprechend seine Datumskorrektur vornimmt),
aber z.B. ein eifriger Virenscanner die Datei währenddessen noch überprüft und erst danach endgültig schreibt und dem Dateisystem eine Modifikation vorgaukelt.
-> das Datum wird wieder auf das aktuelle Datum gesetzt.

Sch...lecht gelaufen, aber leider nicht vorhersehbar und damit auch nicht vermeidbar.

[franc]

Nachdem der Kopiervorgang abgeschlossen ist, setzt der TC das Verzeichnisdatum explizit auf den ursprünglichen Wert.

Toll! Das ist es. Ich Dödel hab nie gewartet bis TC fertig war mit kopieren, sondern nur gesehen: Datum neu, also abbrechen
Ich wollte nämlich einige Verzeichnisse mit sehr grossen Dateien verschieben auf ein anderes Laufwerk, wobei das Datum wichtig ist.

DANKE für diese hilfreiche und gute Erklärung!

Gruss franc

[JFierce7]

Hallo,

frohes Neues Jahr allerseits!

Vielleicht hat ja noch jemand eine Idee zu folgendem Problem:
Ich habe die Option zum Kopieren des Verzeichnisdatums gesetzt. Beim Kopieren klappt das auch, beim Verschieben bekommt das "oberste" Verzeichnis aber ein neues Datum. Unterverzeichnisse behalten jedoch ihren Zeitstempel.
Den Virenscanner habe ich deaktiviert ohne Änderung. Schließlich habe ich noch den Process Monitor gestartet und dabei sehe ich, dass nur der TC auf das Verzeichnis zugreift und dass dieser das aktuelle Datum setzt, nicht das originale.
Seltsamerweise funktioniert alles richtig auf einem anderen PC und mit den Verzeichnissen, die ich testweise erstelle - nur eben mit den "echten" Verzeichnissen nicht. Eine neue wincmd.ini brachte keine Abhilfe. Nun gehen mir die Ideen aus.

Viele Grüße

Edit: Zwischenzeitlich habe ich noch diesen Beitrag gefunden:
http://www.ghisler.ch/board/viewtopic.php?t=17952
Bemerkenswert ist aber, dass TC (7.04a) eben *nicht* den gewünschten Datums-/Zeitwert setzt, sondern den aktuellen. Process Monitor zeigt dies in den Details der "Operation" SetBasicInformationFile an.
Es kann auch kein Rechteproblem sein, da einerseits alle Rechte vorhanden sind (Vollzugriff) und andererseits beim Kopieren alles funktioniert.

Edit2: Noch eine neue Erkenntnis: Erstelle ich selber ein Verzeichnis, dessen Datum ich zwecks Test explizit setze, kann ich das beschriebene Verhalten beobachten, wenn das Verzeichnis mehr als einen Eintrag hat. Mit nur einem Eintrag funktioniert's.
Seltsam - sowas hab' ich (mit dem TC) bisher noch nicht gesehen, an keinem Rechner.

[Dalai]

@JFierce7: Welches Dateisystem verwendest du jeweils? Bei NTFS wundert mich das Verhalten nicht, weil dort das Vaterverzeichnis immer das Änderungsdatum der neusten Datei bekommt, analog zu Ext2/Ext3 bei Linux. Bei FAT32 hingegen wird nur das Datum der Dateien selbst geändert, nicht das des Vaterverzeichnisses.

MfG Dalai

[JFierce7]

@Dalai:

Ja - ist NTFS. Aber:

Zum einen klappt's ja auf anderen Rechnern und auch beim Kopieren bzw. Verschieben mit nur einer Datei im Verzeichnis.
Zum andern bekommt ja das Elternverzeichnis nicht das Datum der ältesten oder neuesten Datei, sondern das aktuelle Datum der letzten Änderung (z. B. Löschen oder Hinzufügen von Dateien). Aber gerade dafür ist ja die Option im TC gedacht.
Leider scheint aber aus irgendeinem Grund der TC seiner Aufgabe in diesem Fall nicht gerecht zu werden...

[Dalai]

Zum andern bekommt ja das Elternverzeichnis nicht das Datum der ältesten oder neuesten Datei, sondern das aktuelle Datum der letzten Änderung (z. B. Löschen oder Hinzufügen von Dateien).

Ja, das wollte ich auch schreiben... so hatte ich es gemeint. Meine Aussage oben stimmt also nur beim Hinzufügen/Ändern von Dateien, nicht für's Löschen.

Leider scheint aber aus irgendeinem Grund der TC seiner Aufgabe in diesem Fall nicht gerecht zu werden...

Das liegt sicherlich nicht am TC, wenn es auf anderen PCs funktioniert. Hier spielen andere Dinge wie Version von NTFS, OS und Patchstand eine Rolle. Zum Anderen kannst du den TC ausschließen, indem du ihn mit einer frischen INI startest:

Code: Select all

totalcmd.exe /i="%temp%\fresh.ini"

MfG Dalai

[JFierce7]

Sooo - jetzt (vorübergehend abschließend?) etwas ganz merkwürdiges:
Nachdem meine Tests am 25.12. und 1.1. nach vielgestaltigen Tests jeweils das obige Resultat brachten, funktionierte es am 2.1. morgens und abends einwandfrei.
Leider habe ich z. Z. keine Möglichkeit, weiter zu testen, ob es nur an ungeraden Tagen nicht funktioniert
Ich bin mir nicht ganz sicher, ob ich nach den Tests am 1.1. vor Mitternacht schon mal neu gebootet hatte, jedenfalls funktionierte es dann am 2.1. kurz nach Mitternacht beim Zugriff auf eine externe Platte und anschließend auch lokal (bis dahin waren alle Tests lokal). Und am Abend nach einem Neustart auch.
Momentan reime ich mir zusammen, dass nach ein paar Updates diverser Programme vielleicht das Dateisystem oder der Windows-Installer zu dem Problem geführt haben könnten.
Seltsam, seltsam. Vor allem dann auch an zwei Tagen. Und sicherlich nur schwerlich zu reproduzieren.
Irgendwie bleibt allerdings noch als Faktg bestehen, dass der TC nach dem Verschieben das aktuelle Datum gesetzt hat (s.o.: ProcMon zeigt dies als Details der Operation SetBasicInformationFile an).