Datei Time (Erstellung, Bearbeitung, letzter Zugriff) mit unterschiedlichen Ergebnissen

    • Offizieller Beitrag

    Ich benötige für Synchronisationsvorgänge die Datei-Time Werte mit Milisekunden und verwende deshalb _Date_Time_GetFileTime zur Abfrage.

    Laut Funktionsbeschreibung gibt es zwar Probleme in der Verfügbarkeit der Infos abhängig vom Dateisystem. Aber grundsätzlich sollten zumindest die Dateiinformationen identisch abfragbar sein:

    [0] - $tagFILETIME structure with the date and time the file was created

    [1] - $tagFILETIME structure with the date and time the file was accessed

    [2] - $tagFILETIME structure with the date and time the file was modified

    Das stimmt, wenn ich Dateien von der Festplatte (NTFS) abfrage.

    Bei Abfrage von einem USB-Stick (NTFS) ist Last Access eindeutig das Create-Datum (am Ältesten).

    Bei einem anderen USB-Stick (NTFS, derselbe Hersteller) ist das Create-Datum OK. Aber Modified ist frischer als Last Access? Wie kann eine Datei modifiziert sein, ohne dass darauf zugegriffen wird?

    Auf einer SD-Card im NTFS stimmt die Zuordnung.

    Obwohl alle Datenträger NTFS haben, bekomme ich unterschiedliche Ergebnisse. Für mich unerklärlich.

    Vielleicht könnt ihr mal bei euch mit verschiedenen Datenträgern testen und mitteilen, was bei euch rauskommt.

    Testskript:

  • Bei einem anderen USB-Stick (NTFS, derselbe Hersteller) ist das Create-Datum OK. Aber Modified ist frischer als Last Access? Wie kann eine Datei modifiziert sein, ohne dass darauf zugegriffen wird?

    Naja, steht ja eigentlich schon in dem verlinkten Autoit Hilfeeintrag von dir?

    Zitat


    NTFS delays updates to the last access time for a file by up to one hour after the last access.

    Hier im Übrigen die komplette Fassung von Microsoft:

    https://msdn.microsoft.com/de-de/library/…0(v=vs.85).aspx

    Bei externen Medien kommt evtl. auch noch der Schreibcache stärker ins Spiel als das bei lokalen Medien der Fall ist. Dadurch kann der Timecode dann ggf. schon ein wenig von der entsprechenden User Aktion abweichen.

    Der Microsoft Artikel erwähnt außerdem noch "nicht geschlossene" Filehandles, was beim unsauberen Trennen von USB Medien passieren könnte.

  • Hallo BugFix

    Mir ist aufgefallen, dass du in deiner Funktion "modified" und "accessed" vertauscht hast.

    Ich habe das mal auf zwei USB-Sticks und meiner Festplatte getestet - alle NTFS formatiert. Die Zeiten sind zwei Stunden in der Vergangenheit, scheinen aber ansonsten zu stimmen. Beim Kopieren einer Textdatei auf einen USB-Stick wurden created und accessed Zeit auf Kopierzeitpunkt gesetzt. Die modified Zeit blieb aber erhalten. Die accessed Zeit hat sich bei Änderungen der Datei nicht geändert sondern blieb bisher gleich der created Zeit. Die modified Zeit hat sich aber direkt korrekt geändert.

    (Die accessed Zeit kann ich später noch einmal prüfen. Laut Hilfe kann es ja eine Stunde dauern, bis man Änderungen sieht..)

    Grüße autoiter

  • BugFix

    OS = xp SP3 32 bit...

    RAM Disk fat32

    Created: 2018/03/30 12:39:35.750

    Modified: 2018/03/29 22:00:00.000

    Last Access: 2018/03/30 12:39:36.000

    auf Localer Platte NTFS:

    Created: 2018/03/30 12:46:41.531

    Modified: 2018/03/30 12:46:41.531

    Last Access: 2018/03/30 12:46:41.531

    auf ntfs usb stick (Rufus als Format Tool)

    Created: 2018/03/30 12:52:46.468

    Modified: 2018/03/30 12:52:46.468

    Last Access: 2018/03/30 12:52:46.468

    ----> Also auch hier jeweils eine 2 Stunden Differenz

    Hinweise auf Suchmaschinen finde ich überflüssig - wer fragt hat es nicht gefunden oder nicht verstanden. Die Antwort gibt sich oftmals schneller als der Hinweis auf Dr. Goggle & Co.

    Ab 19-10-22 ergänzt um:

    Die Welt wird nicht bedroht von den Menschen, die böse sind, sondern von denen, die das Böse zulassen. (Albert Einstein)

    2 Mal editiert, zuletzt von Peter S. Taler (30. März 2018 um 15:35)

  • BugFix

    das von Dir beschriebene Phänomen ist mir so noch nicht untergekommen. Als Denkansatz: Formatier doch mal alle Sticks mit dem gleichen Tool? Mich würde tatsächlich interesieren ob der Effekt dann weg ist?

    Virenscanner im Einsatz? Indexer? Irgendetwas, was auf den Stick zugreift - ev. ein Windows eigener Prozess? Ist das bei allen Dateiendungen so?

    Edit: Kann es sein, dass man den Begriff last Acsess unterschiedlich versteht? Ein Umbenennen der Datei kein "last acess" ist? Ein Öffnen und neu schreiben schon?


    Frohe Ostern

    Peter

    Hinweise auf Suchmaschinen finde ich überflüssig - wer fragt hat es nicht gefunden oder nicht verstanden. Die Antwort gibt sich oftmals schneller als der Hinweis auf Dr. Goggle & Co.

    Ab 19-10-22 ergänzt um:

    Die Welt wird nicht bedroht von den Menschen, die böse sind, sondern von denen, die das Böse zulassen. (Albert Einstein)

    Einmal editiert, zuletzt von Peter S. Taler (30. März 2018 um 16:19)

    • Offizieller Beitrag

    Hallo,

    die 2 Stunden Zeitunterschied kommen daher, dass die Zeiten in UTC gespeichert werden. Das ist ja auch sinnvoll wenn man z.B. Dateien in verschieden Zeitzonen miteinander vergleichen will. Mit der Funktion _Date_Time_FileTimeToLocalFileTime kann man sie in die Lokale Zeit konvertieren.

    Wenn du eine Datei immer nur zwischen gleichen Dateisystemen kopierst, sollte die Modified-Zeit immer die gleiche sein, solange die Datei nicht verändert wurde.

    Problematisch ist es wenn es sich um unterschiedliche Dateisysteme handelt. Bei FAT (FAT32, exFAT ...) hat die Modified-Zeit nur eine Genauigkeit von 2 Sekunden. das heisst wenn die Zeit in NTFS z.B. 21:14:40.624 ist dann ist die Zeit in FAT 21:14:42.000. Es wird also immer auf die nächsten 2 Sekunden aufgerundet.

    Richtig Interessant wird es wenn dann noch ein Dateisystem dazukommt, das zwichen Groß- und Kleinschreibung unterscheidet.

    • Offizieller Beitrag

    Naja, steht ja eigentlich schon in dem verlinkten Autoit Hilfeeintrag von dir?

    Nicht wirklich. Ich habe Dateien betrachtet, auf die letztmalig vor > 1 Monat zugegriffen wurde. Das Problem der verzögerten Info besteht somit nicht.

    Mir ist aufgefallen, dass du in deiner Funktion "modified" und "accessed" vertauscht hast.

    Oops. :huh:

    Unabhängig von dieser Vertauschung habe ich jetzt mal diverse Dateien betrachtet (vergleichsweise die Angaben im Explorer angesehen).

    Fazit: Die Infos zur Dateizeit sind nur dann zu irgendwas nütze, wenn die Datei auf ihrem "Entstehungsort" (Laufwerk) verbleibt. Jeder Kopiervorgang kann zu einer Änderung der Dateiinfos führen.

    Ich habe noch kein System erkannt, wann und wann nicht Änderungen stattfinden.

    Landet die Datei auf einem anderen physischen Laufwerk, wird das Erstelldatum auf den Zeitpunkt des Kopiervorgangs gesetzt. Kann man nur unterbinden, wenn man Schreibschutz setzt. Spaßigerweise werden die Daten für Änderung und Zugriff nicht angepasst und liegen jetzt vor dem Erstelldatum! -- Das ist die Ursache für die entdeckten Diskrepanzen.

    Ich bin mir aber nicht sicher, ob das wirklich immer genau so passiert.

    Meiner Meinung nach sind die Datei-Zeit-Informationen keine zuverlässigen Angaben um Datei zu vergleichen.

  • BugFix ,

    ok, hier siht man mal wieder deutlich, wie ein Vorgehen, auch unter erfahrenen Nutzern, gar nicht umfangreich genug beschrieben werden kann. Ich habe die Dateien nicht kopiert, sondern jeweils neu angelegt. Werde aber heute Nachmittag entsprechend Bugfix Vorgaben, das mal ansehen.

    Um Dateien zu vergleichen - scheint mir der Ansatz nicht richtig. Das fängt schon bei den Zeitstempeln an. Eine *.txt Datei innerhalb einer engen Zeitspanne mehrmals, mit mini Veränderungen - und sei es nur ein Buchstabe - zu speichern, läßt sich ja machen --> wer nur Zeitstempel verglecht...

    Kann autoit keine Hashwerte zu Dateien....?

    Gruß

    Peter

    Hinweise auf Suchmaschinen finde ich überflüssig - wer fragt hat es nicht gefunden oder nicht verstanden. Die Antwort gibt sich oftmals schneller als der Hinweis auf Dr. Goggle & Co.

    Ab 19-10-22 ergänzt um:

    Die Welt wird nicht bedroht von den Menschen, die böse sind, sondern von denen, die das Böse zulassen. (Albert Einstein)

  • Hallo BugFix

    Bei meinen Tests haben die modified Zeiten immer gepasst. Wahrscheinlich genügt es Dateiname und modified Zeit zu vergleichen, oder?

    Jedenfalls wenn alles von NTFS Laufwerken kommt. Siehe die interessanten Auslassungen von bernd670 in Beitrag 6.

    Grüße autoiter

  • Naja ich vermute er will nicht nur ein Backup, sondern eher eine Mehrwege Synchronisation und ist deswegen auf die Timestamps gekommen . Das dürfte auch die einzige Möglichkeit sein zu beurteilen welche der beiden Kopien jetzt die aktuelle Fassung darstellt. (z.B. Daten wurden andernorts auf USB Stick verändert und sollen lokal nun auch aktuell sein, bzw. umgekehrt)

    Für ein einfaches Einwege Backup langt normalerweise ein Dateigrößenvergleich um eine Veränderung der Daten festzustellen. Im Zweifelsfall (gleiche Dateigröße) würde ich dann noch das modify Datum prüfen und bei Abweichung einen Hashwertvergleich durchführen (sofern zeittechnisch vertretbar).

    • Offizieller Beitrag

    Wie richtig vermutet, will ich Dateistand identisch halten auf mehreren Standorten (PC, Laptop und Sicherungsstick).

    Ich bearbeite Dateien mal am PC, mal am Laptop und möchte wechselseitig auch von dort sichern. Die Synchronisationsregeln festzulegen ist schon kompliziert genug. Somit wären die FileTime-Informationen eine wichtige Information.

    Da diese aber nicht zwingend zuverlässig sind, werde ich einen anderen Weg finden müssen.

    Als Idee:

    In jedem Ordner eine Datenbankdatei mit Auflistung aller Dateien des Ordners und dem zugehörigen Datum der letzen Änderung, welches bei jedem Speichern der Datei aktualisiert wird.

    Auf dem anderen PC /Datenträger wird analog abgelegt. Um die Notwendigkeit der Synchronisation festzustellen, vergleiche ich dann die Änderungszeiten aus den Datenbanken. Die sind in sich konsistent und unabhängig von ungewollten Änderungen der Dateiinfo.

    Ich habe schon verschiedene Sync-Tools getestet, aber noch keines gefunden, dass mich überzeugen konnte. Deshalb möchte ich mir etwas skripten, was genau das tut, was ich will. ;)

  • Wie wäre eine serverbasierte Lösung? Von unserem Dokumentenmanagementsystem kenne ich das so, dass man eine Datei zunächst zum bearbeiten auscheckt. Solang die Datei so gesperrt ist darf kein anderer Anwender die Datei auschecken. Nach dem Bearbeiten wird die Änderung mit dem Server synchronisiert und die Datei wieder freigegeben. Alle Vorgängerversionen bleiben serverseitig erhalten und können bei Bedarf wiederhergestellt werden, inkl. Protokollierung wer wann Änderungen vorgenommen hat.

    • Offizieller Beitrag

    Unison habe ich unter Linux im Einsatz, um auf 3 Proxy-Servern die Konfigurationen zu syncronisieren.

    Wenn auch eine Versionskontrolle benötigt wird, kann ich dir Git empfehlen, das funktioniert auch ohne Server.

  • Wenn ich mir die letzten Posts so ansehe, ist es dann nicht einfacher eine Datenquelle bereitzustellen, die ein Sync der Daten überflüssig macht, da es keine "doppelte" Datenhaltung gibt?

    Unison arbeitet auf Basis der lokalen Dateisysteme. Wer will bei so viel Einschränkungen sich auf Software verlassen, die die Fehler des zugrundeliegenden "menschelns" nicht in den Griff bekommen kann...

    Gruß

    Peter

    Hinweise auf Suchmaschinen finde ich überflüssig - wer fragt hat es nicht gefunden oder nicht verstanden. Die Antwort gibt sich oftmals schneller als der Hinweis auf Dr. Goggle & Co.

    Ab 19-10-22 ergänzt um:

    Die Welt wird nicht bedroht von den Menschen, die böse sind, sondern von denen, die das Böse zulassen. (Albert Einstein)

    • Offizieller Beitrag

    ist es dann nicht einfacher eine Datenquelle bereitzustellen, die ein Sync der Daten überflüssig macht, da es keine "doppelte" Datenhaltung gibt?

    Nein, keine Option. Wenn ich im Firmenstammsitz arbeite (1-mal im Monat für eine Woche), habe ich meinen PC an dem ich Dateien bearbeite, die ich sonst auch auf meinem Laptop vorhalte und bearbeite. Nur eine Datenquelle (z.B. USB-Stick) wäre theoretisch denkbar, Jedoch als alleinigen Datenspeicher möchte ich den nicht haben. Jedes mal kpl. kopieren ist schwachsinnig, also bleibt nur Synchronisation.

  • BugFix ,

    ja dann muss es wohl so sein :).

    Wenn sich die Zahl der "Zugreifer" gering hällt, läßt sich wohl auch die Zahl der Fehlerquellen minimieren.

    Gruß

    Peter

    Hinweise auf Suchmaschinen finde ich überflüssig - wer fragt hat es nicht gefunden oder nicht verstanden. Die Antwort gibt sich oftmals schneller als der Hinweis auf Dr. Goggle & Co.

    Ab 19-10-22 ergänzt um:

    Die Welt wird nicht bedroht von den Menschen, die böse sind, sondern von denen, die das Böse zulassen. (Albert Einstein)