Moin!

In der Shoutbox längt sich die Diskussion mit jaenicke langsam etwas, damit die Nachwelt auch noch was davon hat also mal ein Thema

Es um die Behandlung von Zeitzonen im Dateidatum (nehmen wir der Einfachheit halber mal das LastModified-Datum). Laut der MSDN-Seite dazu ist das alles eher kaputt, und je nachdem welche Funktion man benutzt ist es mehr oder wenider zufällig welche Zeitzone (oder UTC) das zurückgegebene Datum hat, abhängig davon wann es geschrieben wurde und wann es gelesen wird.

Was ich eigentlich suche ist eine Variante, das Datum auf einen Wert (der mir in UTC gegeben ist) zu setzen und später (egal wie viele Zeitumstellungen dazwischen waren) exakt die gleiche Zahl wieder zu bekommen.
Was der Explorer anzeigt wäre mir erstmal egal, solange ich innerhalb meines Programms den Wert zuverlässig rekonstruiert bekomme. Der Wert muss nicht beim kopieren über Dateisysteme erhalten bleiben (auch wenn das schön wäre), die Methode sollte aber mit allen Dateisystemen klarkommen; NTFS, FAT und SMB erstmal, CDFS und UDF kann man ignorieren weil read-only.

So wie ich das sehe geht das nicht wirklich zuverlässig, oder?

Viele Grüße,
Martok

Ich zitiere mal deinen eigenen Link:

msdn.microsoft.com/e...724290(v=vs.85).aspx hat folgendes geschrieben:

FindFirstFile retrieves the local time from the FAT file system and converts it to UTC by using the current settings for the time zone and daylight saving time. Therefore, if it is daylight saving time, FindFirstFile takes daylight saving time into account, even if the file time you are converting is in standard time.

Sprich:
Mit FindFirst solltest du die korrekte Zeit bekommen.

Und wenn man mal in Delphi schaut, findet sich in der Unit SysUtils eine Funktion GetFileAttributesExEmulated, die genau diese Informationen abruft.

Das Setzen sollte immer korrekt laufen, da dabei ja kein Lesecache dazwischenspielt. Sprich egal ob TFile.SetCreationTimeUtc, TFile.SetLastAccessTimeUtc oder TFile.SetLastWriteTimeUtc, es sollte alles gehen. (Bzw. die plattformabhängigen APIs bei Uralt-Delphiversionen.)

jaenicke hat folgendes geschrieben :

msdn.microsoft.com/e...724290(v=vs.85).aspx hat folgendes geschrieben: Therefore, if it is daylight saving time, FindFirstFile takes daylight saving time into account, even if the file time you are converting is in standard time. Sprich: Mit FindFirst solltest du die korrekte Zeit bekommen.

Eben grade nicht. Wenn jetzt DST ist, wir die abgezogen.
Wenn ich das Datum im Sommer setze und im Winter abfrage, ist da eine Stunde Unterschied. Das könnte man zwar teilweise kompensieren indem man die komplette TZ-Berechnung selber macht (also die aktuelle Zeitzone wieder abzieht, prüft welche Verschiebung zu diesem Datum aktuell war und dann wieder zurückrechnet), aber schön ist was anderes.

Auf NTFS ist das alles einfach, das stimmt allerdings. Da ist UTC auf der Platte und Zeitzonen sind nur in den Zugriffsfunktionen relevant und einfach rausrechenbar.

Martok hat folgendes geschrieben :

Eben grade nicht. Wenn jetzt DST ist, wir die abgezogen. Wenn ich das Datum im Sommer setze und im Winter abfrage, ist da eine Stunde Unterschied.

Das gilt dann aber auch für GetFileTime und alle anderen Funktionen.

jaenicke hat folgendes geschrieben :

Das gilt dann aber auch für GetFileTime und alle anderen Funktionen.

Genau mein Punkt
Wie gesagt, die absolute Zeit wär mir ja egal, aber durch diesen Effekt ändert sich die Verschiebung. Das sollte eigentlich ein Hint für einen Updater werden, aber so wird das nix.

Wobei die Frage ist inwiefern man FAT32 noch unbedingt unterstützen muss.

Bei einem Updater frage ich mich allerdings was der mit dem Dateidatum so wichtiges macht. Denn um festzustellen was aktualisiert werden muss, bringt das ja ohnehin nicht viel. Dafür kann man ja einfach Hashs nutzen, ggf. nach einer nicht erfolgreichen Datumsprüfung.

Ein Hash, den man nicht berechnet, kostet keiene Zeit (und IOps)

Die Idee war, die Datei auf etwas bekanntes zu stampen. Wenn im Update etwas anderes gegeben ist, ist die Datei irgendwie anders. Nur wenn das und die Größe gleich ist, muss der Hash berechnet werden. Geht hier eventuell um Gigabyte, da will ich so früh wie möglich eine Aussage haben ohne die Daten lesen zu müssen.

Ich mache das in der Regel stufenweise. Dateidatum + Größe, Hash der ersten paar Byte (bei mir in der Regel 4KiB) und erst wenn diese Angaben nicht übereinstimmen berechne ich den kompletten Hash.

Je nach Daten kann man die Heuristik natürlich auch noch ausbauen.

jaenicke hat folgendes geschrieben :

Hash der ersten paar Byte (bei mir in der Regel 4KiB)

Keine dumme Idee. Bei den konkreten Daten vielleicht eher von den letzen 4k, aber das könnte das IO-Problem klein genug machen.

Damit wäre das Thema des Threads hier auf "rein interessenhalber" reduziert. Aber meine Feststellung vom Anfang bleibt: meine Güte, ist das kaputt alles