tc.creationdate tc.writedate usw und Kopieren

[marekmand]

Gibt es irgendwie Möglichkeit beim Kopieren usw mit extra Einstellung die Zeiten der Dateien und Ordnern zu behalten?

Stellen wir mal vor, wir machen Backup von Festplatte auf eine andere Festplatte. Wir machen Backup z.B um Windows neu zu installieren und Festplatte clean zu machen. Dabei wollen wir auch sicherlich das Gelöschte teilweise aus Backup (der auf einer anderer Festplatte liegt) wiederherzubauen.

Problem:
Dabei gehen heute mit aktuellen Total Commander die für mich wertvolle Zeitattributen verloren, besonders
tc.creationdate
was den heutigen Wert bekommt.
Die historische Reihenfolge wann was erstellt wurde, geht verloren.

Wäre aber super falls man Kopieren mit extra Einstellung sowas beeinflussen könnte, dass man hin und herkopieren könnte und man immer noch seine eigene Geschichte was man und wann man irgendwas machte, nach Jahren auch herauslesen kann.

Ich habe sowas commandline Progrämmchen gefunden
http://www.softtreetech.com/24x7/archive/47.htm
"Use FileTouch utility to change file dates and times."
die
tc.creationdate
tc.writedate
zu modifizieren erlaubt.

Aber das ist doch fürchterlich, kann man ja nicht per jede Datei sowas Befehl manuell eingeben bei heutigen mehrhundergigabyte-millionendateienaufsich-Festplatten...
Also wäre es schön wenn TotalCommander sowas "force file creation time equal to..." Funktionalität hätte.


(meine Muttersprache ist nicht Deutsch, hoffe sie haben meist verstanden was ich sagen-fragen wolle ;D)

[HolgerK]

Kleiner Tip:
Wenn du anstelle von Copy <F5> eine Zip-File mit Pack <Alt-F5> erzeugst, dann bleibt das Datum der Verzeichnisse erhalten.
Erfreulicher Nebeneffekt: die Archive benötigen wesentlich weniger Platz, und lassen sich mit TC auch sehr komfortabel durchsuchen

Gruß
Holger

[marekmand]

Das ist aber keine Lösung für dieses Problemchen, weil wenn ich diese ZIP-File auspacke dann die Zeiten (TotalCommanders Attributwertspalte tc.creationdate) der Dateien hergestellt aus ZIP-File, nun im Filesystem HEUTIGE JETZTIGE Zeitwerten sind und nicht dieselben, die sie einst auf Festplatte waren.

Ich wünsche 1:1 Kopie von Dateien und deren Zeiten (created, last modified), und dass ich sowas problemlos 1:1 kopieren mittels Totalcommander kann.

Woran liegt es, dass du von dir Vorgestelltes als eine Lösung sah?
Du wahrscheinlich siehst die Werte bei deiner Totalcommander gleich, weil du nicht dein Totalcommander so konfiguriert hast, dass er auch die Zeit der Erstellung von Dateien anzeigt. In FULL VIEW Modus (CTRL+F2) zeigt Totalcommander dir eine Attributwertspalte "Date", was aber NUR die Zeit der letzter Modifikation bedeutet. Die IST NICHT die Zeit der ersten Erstellung (FILE CREATED, tf.creationdate) der Datei. Sondern, der ist Wert von der letzten Modifikation.

Falls du die "richtigen" Zeiten ansehen willst, solltest du
1) Datei per Datei aus Kontextmenü "Properties" wählen und in "Properties"-Dialogfenster die alle Zeiten ansehen.
ODER
2) Totalcommander voraus so konfigurieren, dass er dir diese Werten in Spalten anzeigt
Also Menü: Configuration->Options->Custom columns.
Da New Button drücken, dann "Add column" Button drücken, dann in dieser Tabelle da in der letzten Spalte auf "+"-Formularbutton drücken und von erschienenen Menü tc.CREATIONDATE wählen.
Falls du jetzt diese diese "custom Anzeigemodus" im Panel aktiviers, siehst du, dass die Werte der Originaldateien und der Dateien eingepackt-zu-ZIP-ausgepackt-aus-ZIP nicht gleich sind.


Die Zeitattribut was nicht verloren geht ist
tc.writedate
das heisst die Zeit der letzter Modifikation der Datei.
Und sobald man so ein Datei modifiziert, bekommt der auch eine neue "last modified" Wert und man kann dann nie mehr sagen wenn's ursprünglich hergestellt wurde, denn FileCreated ist beim Kopieren "falsch" geworden.

Ich aber will mit Totalcommander so kopieren, dass auch FILE CREATED DATE (tc.creationdate) seine alte Wert bekommt.

Also ZIP-Packer hilft hier nicht.
Man bräuchte hier die Funktionalität Totalcommanders zu erweitern.
Hoffe, dass jemand anderer ausser mich es auch so sieht und so eine Funktionalität wünscht.

[icfu]

Jo, das wünsche ich mir auch!

Als Beispiel für einen Dateimanager, bei dem man das Erstellt-Attribut beim Kopieren übernehmen kann, sei – mal wieder – Directory Opus genannt...

Icfu

[Stitscher]

Jo, das wünsche ich mir auch!

Dem Wunsch schliesse ich mich ebenfalls an.
Wäre ne sehr schöne Sache.

[marekmand]

Ich bin total getäuscht, dass man so wenig Interesse auf so was Funktionalität hat,
was wichtig wird, wenn man seine eigene Sachen auf andere Festplatte archiviert.

Naja kann sein, dass meist von euch keine zweite Festplatte haben.
Und falls haben sie, dann sie sowas kopieren mit festen Datum nicht brauchen.
ABER.
FALLS sie es aber später eines Tages brauchen werden, um ihre Dateien weiter chronologisch zu behandeln und auch so zu BEHALTEN, dann ist alles kaputt mit Totalcommander und Kopieren und an diesem Tag werden sie verfluchen, weil alle eure mühsam geschaffene Dateien ihre Datum verlieren beim Kopieren mit TC.


Worüber ich sprach war, das sie nach Jahren bei ihre kopierte Dateien möglicherweise feststellen können, wenn sie erst geschaffen wurden. Dass beim Überkopieren der gleichen Dateien auf Zielort immer das älteste Datum gesetzt wird usw.
Dass sie sagen können, aha an diesem Tag vor zwei Jahren habe ich mich damit beschäftigt usw. Datum der Dateien - dass ist ihr Tagebuch von eurem Leben... Wollt ihr sowas nicht behalten?

[HaPe]

Ich kann mich nur anschließen, eine Übernahme von created-date UND last-modified-date beim Kopieren wäre SEHR schön und hilfreich! Habe schon oft bei selbsterstellten Dateien aufgrund dieser Zeitstempel recherchiert, wie der genaue Ablauf bei irgendwelchen Vorgängen war.

Und wenn es andere Programme hinbekommen, sollte TC das wohl auch hinbekommen, von wegen Ehre und so

[icfu]

@marekmand:
Enttäuscht, nicht getäuscht.
Das Thema wird halt nicht zum ersten Mal behandelt; die Leute sind müde, immer wieder die selben Themen zu diskutieren, zumal es sich hier eigentlich um eine SELBSTVERSTÄNDLICHKEIT handelt, die ein Dateimanager beherrschen MUSS.

Der einzige, der hier noch was sinnvolles zum Thema beisteuern kann, ist ghisler, denn er muß sich dafür entscheiden, es endlich einzubauen.

Icfu

[HaPe]

Umso wichtiger, dass man es ab und zu mal wieder anspricht, damit es nicht in Vergessenheit versinkt

[ghisler(Author)]

Kein mir bekannter Dateimanager kopiert die Created und Last modified-Daten! Wieso? Die Daten haben folgende Bedeutung:
- Created: Zu diesem Zeitpunkt wurde die Datei neu angelegt. Bei kopierten Dateien ist das der Zeitpunkt, wo die Kopie erstellt wurde.
- Modified: Zu diesem Zeitpunkt wurde der INHALT der Datei zuletzt vom Benutzer verändert. Dieses Datum muss deshalb kopiert werden.
- Last accessed: Zu diesem Zeitpunkt wurde zuletzt auf die Datei zugegriffen (lesend oder schreibend). Dies ist sowohl bei Quelle wie beim Ziel der Zeitpunkt des Kopierens! Es macht deshalb auch hier keinen Sinn, das Datum zu kopieren.

[icfu]

Kein mir bekannter Dateimanager kopiert die Created und Last modified-Daten!

Warum erwähne ich dann Directory Opus oben?
Die Betonung liegt wohl auf "mir bekannter". Ab und an tut ein Blick auf die Konkurrenz ganz gut.

- Created: Zu diesem Zeitpunkt wurde die Datei neu angelegt. Bei kopierten Dateien ist das der Zeitpunkt, wo die Kopie erstellt wurde.

"optional" ist hier das Zauberwort. Die meisten Leute könnten mit dem tatsächlichen Erstellungsdatum des INHALTS der Datei sicherlich mehr anfangen als mit dem Erstellungsdatum der Datei auf einem Datenträger/in einem Dateisystem.

- Modified: Zu diesem Zeitpunkt wurde der INHALT der Datei zuletzt vom Benutzer verändert. Dieses Datum muss deshalb kopiert werden.

Stimmt.

- Last accessed: Zu diesem Zeitpunkt wurde zuletzt auf die Datei zugegriffen (lesend oder schreibend). Dies ist sowohl bei Quelle wie beim Ziel der Zeitpunkt des Kopierens! Es macht deshalb auch hier keinen Sinn, das Datum zu kopieren.

Doch, das würde Sinn machen, wenn Microsoft das vernüntig implementiert hätte und nicht bei jedem Käse das Attribut updaten würde. Dennoch gibt es Wege, das last accessed-Attribut mitzukopieren und in genau diesen Anwendungsfällen macht das auch Sinn.

Icfu

[ghisler(Author)]

Zu last accessed: Es ändert sich doch aber, wenn man die Datei kopiert! Soll es das etwa nicht? Man hat damit ja auf die Datei zugegriffen...

[sqa_wizard]

Dennoch gibt es Wege, das last accessed-Attribut mitzukopieren ...

Natürlich, aber wie willst du das überprüfen ?
Schon das Nachschauen wann eine Datei "last accessed" wurde ändert das Attribut auf das aktuelle Datum !

[icfu]

Zu last accessed: Es ändert sich doch aber, wenn man die Datei kopiert! Soll es das etwa nicht? Man hat damit ja auf die Datei zugegriffen...

Im Idealfall müßte der Anwender selbst entscheiden können, welche Aktionen als Zugriff gewertet werden und welche nicht, denn Bedürfnisse sind unterschiedlich.

Ich verweise mal auf die XXCOPY-Referenz:
http://www.xxcopy.com/xxtball.htm#xxtb_01

----- The following switches control timestamps -----

/TTA Touches (modifies) timestamp of Last Access of src.
/TTA0 Preserves timestamp of Last Access of src (default).

/TCA Copies the timestamp of Last Access fm src to dst.
/TCA0 Uses current time for dst Last Access (default).

/TCC Copies the timestamp of Create Time fm src to dst.
/TCC0 Uses current time for dst Create time (default).

/TCW Copies the Last Write time fm src to dst (default).
/TCW0 Uses current time for dst Last Write time.

http://www.xxcopy.com/xxtball.htm#xxtb_15

The case with the Last-Access date:

This parameter is also a very controversial value that goes with
every file in the Win32 system. The Last-Access date is set whenever
the file is "Accessed" by a program. Then, the next question is
what really constitutes an "Access" to a file?

Is opening the file by a program, by any program, treated as an
"Access"? Thank God, the answer is no. If that were the case,
whenever the Windows Explorer displays an executable file using its
icon (which is stored inside the file), the Last-Access date would
be set to the current date. That is because display of the icon
involves fist opening the file and reading the contents to locate
the internal icon. In this case, although the treatment of the icon
is rather elaborate under the cover, it is not regarded as an "Access".
On the other hand with .EXE and .DLL files, executing the program
constitute the Last-Access. That makes sense.

But, there are plenty of silly mistakes committed by Microsoft's
programmers which makes the Last-Access date of little use. The
possibly the worst program mistake with this value is by Windows
Explorer.

As shown above, when you click the right button on an icon of a file
and select the properties menu, you can examine the Last-Access date
(in this case you get only the date without time) along with the other
two file date values. But, if you are alert, you will notice that
the Last-Access date is always today's date. Yes, the very act of
examining the Last-Access date value triggers the update of the value.
That is sad. Very sad.

When a system administrator makes a regularly scheduled backup, he
usually performs a full backup every so often, copying every file
in a drive. Now, that is an act of Access. Copying a file will
also update the Last-Access date.


Conclusion:

If Microsoft's programmers had been very careful not updating the
Last-Access values under certain common file access cases, this
value could have become a very useful parameter in file selection
for file management (backup) activities. Unfortunately, they wrote
so many programs that ignored the designer's apparent intention.
Now, it is too late. The Last-Access date is even more useless
than the doomed File-Create date.

We recommend the use of /FC (File-Create date) only in carefully
controlled circumstances. The Last-Access date (selected by /FA)
seems nearly useless for meaningful file management activities.

Original DOS file system had only 32 bytes to represent a file in
the directory. The very restrictive 8.3 filename and the limited
granularity (2 second) in file date are corrected in the Win32
file systems (VFAT). But, the generous allocation of lots of
bytes (24 bytes just to store the file date in three flavors) which
bloats the system resource usage but provides little useful
information seems to symbolize what we know as Windows Operating
System.

Icfu

[raeubi]

Im Idealfall müßte der Anwender selbst entscheiden können, welche Aktionen als Zugriff gewertet werden und welche nicht

Meinen Dank an Euch für diese Diskussion!
Meinen Support an dieser Stelle für konfigurierbare Lösung.
Ein paar mal hatte ich schon selbst angesetzt so was zu posten ...