Moin Gemeinde,
folgende Problemstellung.
Beim Umkopieren von Dateien soll das Originaldatum beibehalten werden.
Da meine Kenntnisse dafür nicht ausreichen habe ich mir aus dem Internet eine Routine geladen die nach dem kopieren der Datei das Datum der Zieldatei umschreibt.
Leider scheint diese Routine nicht 100% zu funktionieren. Manche Daten werden falsch geschrieben.
Beispiel:
Aus dem 01.01.2026 wird der 31.12.2025
Aus dem 01.03.2026 wird der 28.02.2026
Der Februar funktioniert überhaupt nicht. Es fehlt jedes mal ein Tag. Aus dem 15. wird der 14. usw.
Zum Testen hab ich mir eine kleine Routine gemacht anhand derer man das ganze nachvollziehen kann.
Könnte mal jemand bitte da drauf schauen? Füge ich im Anhang bei.
Als Test kann jede beliebige Datei verwendet werden. Es muss in meinem Programm dann nur der Pfad angepasst werden.
Oder hat zufällig jemand eine Routine die zuverlässig arbeitet?
Wünsche allen ein schönes Wochenende
Jörg
Versuch mal so in etwas
Dim OriginalDatum As Date
Dim ZielDatei As Object
OriginalDatum = Datei.DateLastModified
fso.CopyFile Datei.Path, Ziel & "\" & Datei.Name, True
Set ZielDatei = fso.GetFile(Ziel & "\" & Datei.Name)
ZielDatei.DateLastModified = OriginalDatum
Das passt zu Deinem alten Code, ist schon was länger her
Gruß
Holger
Danke Holger, werde ich morgen ausprobieren.
Hallo Jörg,
ZitatBeim Umkopieren von Dateien soll das Originaldatum beibehalten werden.
Was genau meinst du damit? Es gibt 3 Daten: Created, LastAccessed, LastModified. Alle verhalten sich wie erwartet und werden nicht einfach willkürlich beim kopieren geändert. Insbesondere LastModified wird beim Kopieren nicht verändert, deshalb ist der Code aus #1 so auch erstmal etwas sinnfrei.
Knobbi38
Hallo Ulli,
so ein bisschen passt das alles zu dem Thread von Jörg hier (https://www.access-o-mania.de/forum/index.php?topic=28620.0)
Da gabe es schon einiges dazu. Er hat da schon was fertiges so ansatzweise, welches nur angepasst umgearbeitet werden müsste, wenn ich mich richtig erinnere
Gruß
Holger
Hallo Holger,
ja kann sein, aber dann sollte Jörg genauer beschreiben, um was es geht. Wie gesagt, dass letzte Änderungsdatum kann er wohl nicht meinen, dass ändert sich beim kopieren eben gerade nicht.
Gruß
Ulrich
Hallo Holger, Hallo Knobbi,
ich muss wohl weiter ausholen.
Ich kopiere Dateien von meinem Rechner auf ein Webdav-Laufwerk das als W: im Dateiexplorer eingebunden ist.
Dabei werden sowohl das Erstelldatum als auch das Änderungsdatum auf den heutigen Tag gesetzt.
Ich wollte eigentlich erreichen das die beiden Datumangaben erhalten bleiben. Zumindest das Erstelldatum wäre wichtig.
Interessanterweise tritt dieser Effekt nicht auf wenn ich die Datein von z.B. C: auf D: innerhalb des gleichen Computers kopiere.
Ich glaub ich lass das einfach fallen. Holger hat sich schon damit gestern beschäftigt aber das Ergebnis ist immer noch das selbe.
Wünsche allenn eine gute Woche
Jörg
Das hättest du auch früher sagen können. Das Problem ist hinreichend bekannt tritt je nach WebDAV-Client mehr oder weniger auf. Es kann sich z.B im Explorer ändern, im Browser aber möglicherweise nicht. Entweder eine andere Software ausprobieren oder aber vor dem Kopieren die Datei in eine Zip-Datei packen. Dann bleiben die Metadaten erhalten.
Knobbi38
PS:
Vielleicht kannst du auch auf eine anderes Protokoll wie SSH oder SFTP wechseln. Je nach WebDAV Anbieter könnte das damit funktionieren.
Hallo Knobbi,
sorry. Wusste nicht das Webdav damit was zu tun hat.
Ich hab ja wie in #1 beschrieben eine Routine gefunden die das Datum entsprechend setzt.
Warum diese allerdings im Januar und Februar um minus einen Tag versetzt arbeitet ist mir schleierhaft.
Ich dachte die könnte man irgendwie anpassen.
Liebe Grüße
Jörg
Hallo Jörg,
bei deiner Testroutine fängt es schon mit der API-Deklaration für die API-Funktionen an. Diese ist schlichtweg falsch, der Else-Fall passt gar nicht. Nutzt du noch VBA6?
Dann ist die Testroutine für diesen Test nicht gut geeignet. Vor dem Kopiervorgang müssten die Metadaten der zu kopierenden Datei ausgelesen und nach dem Kopiervorgang wieder gesetzt werden. Da die Metadaten immer in UTC-Zeiten kodiert sind, sollte eine Konvertierung eigentlich nicht notwendig sein. Man müsste die ursprünglichen Zeiten einfach nur neu setzen. Bitte nicht mit den Zeiten verwechseln, die im Explorer angezeigt werden – das sind lokale Zeiten!
Ich habe mir von der KI einen Rohentwurf als Ausgangspunkt generieren lassen. Da dabei jedoch noch so viele Fehler auftreten, möchte ich das hier nicht ungeprüft weitergeben. Ein passendes Beispiel wird also noch etwas dauern.
Wie kopierst du eigentlich deine Dateien auf die WebDAV Freigabe? Per VBA, einem Tool oder ...? Access 32- oder 64-Bit?
Knobbi38
Hallo Knobbi,
das Beispiel war auch von einer KI.
Ich verwende Access 2024 und den filecopy Befehl.
64 bit.
Liebe Grüße
Jörg
FileCopy? Hast du die Freigabe als Laufwerk eingebunden? Dann verstehe ich noch nicht, warum das Beispiel von Holger nicht das gewünschte Ergebnis bringt.
Knobbi38
Hallo Jörg, hallo Ulli
ich habe da mal was nachgelesen und da müsste Jörg dann auch noch was zu sagen bezüglich WebDav
Gruß
Holger
1. WebDAV als Laufwerksbuchstabe gemappt D:\
Ja, funktioniert. SetFileTime API arbeitet mit normalen Dateihandles. Windows kümmert sich um die WebDAV-Übersetzung. Erstelldatum, Änderung, Zugriff werden 1:1 gesetzt. Teste ich hier regelmäßig.
2. WebDAV über UNC-Pfad \\server@SSL\DavWWWRoot\
Geht auch, solange Windows den Pfad auflösen kann. CreateFile akzeptiert UNC. Performance ist aber mies, weil jede Datei 3x angefasst wird: Kopieren + Zeit lesen + Zeit setzen.
3. WebDAV-Server unterstützt es nicht
Manche Billig-NAS oder OwnCloud/Nextcloud in Standardconfig ignorieren SetFileTime komplett. Datei wird kopiert, Datum bleibt "jetzt". Kein Fehler, aber Datum falsch.
Hallo Holger,
nach verschiedenen Tests vermute ich Punkt 3. Egal was ich mache. Es wird immer das aktuelle Datum gesetzt.
Damit hat sich das ganze dann auch erledigt.
Liebe Grüße
Jörg
P.S. Trotzdem nochmal ein Nachtrag: Es funktioniert ja auch auf lokalen Dateien nicht richtig. Also zumindest auf meinem Rechner.
Januar und Februar sind jeweils um -1 Tag verschoben.
Hallo Jörg,
ich habe da noch eine Idee. Da es ja mit Deinem WebDav nicht funktionieren wird. Wäre es doch gut, sich das Datum trotzdem zu merken und bei der Rücksicherung wieder zurück zu schreiben.
Daher wenn ich das Datum nicht setzten kann, machen ich folgendes. Ich lege eine Weihach.....accdb.meta Datei an. Dort steht das richtige Uhrsprungsdatum drin. Dass kann man dann zurückschreiben. Sollte es auch noch auf die Uhrzeit ankommen wird es umfangreicher.
Ich habe das auch mal fertig gemacht in Deiner Demo-Datei. Die ich mal hier hoch lade.
Ich kann es leider nicht testen, da ich so eine Umgebung nicht habe.
Ulli wird da bestimmt auch noch eine Idee zu haben.
Gruß
Holger
Hi Holger,
vielen Dank an dich. Ich komme aber erst am Freitag dazu mir das anzuschauen. Wichtig wäre eigentlich nur das Erstelldatum. Optimal wäre es dann natürlich wenn Ändereunsdatum=Erstelldatum wäre.
Liebe Grüße
Jörg
Habe ich ... ;D
Das gilt nicht nur für WebDAV, sondern auch für einige FTP-Implementierungen (musste mit der Fritzbox so meine Erfahrungen machen):
man kann die Metadaten einfach an den Dateinamen vor der Extension einfügen. Die max. Länge für Dateinamen sollte das noch zulassen.
Knobbi38
Hallo Jörg,
du bist da auf etwas gestoßen, dass normalerweise keinem auffällt. Du kannst das Erstellungs- und Modifikationsdatum richtig setzen, aber beim letzten Zugriffsdatum tritt der von dir beschriebene Fehler nachvollziehbar auf.
Ich habe dazu mal die KI befragt und nach hartnäckigem "Nachbohren" habe ich dann auch eine technisch akzeptable Antwort bekommen. Ohne ins Detail gehen zu wollen, liegt es an Windows und die Art, wie es das letzte Zugriffsdatum in Verbindung mit dem NTFS Dateisystem verwaltet. Hier greifen wohl Treiber, Caching, Umrechnungen von UTC / MEZ, Winter-/Sommerzeit usw. in das Geschehen ein. Fakt: du kannst dem letzten Zugriffsdatum nicht so ohne weiteres trauen bzw. es gezielt auf einen gewünschten Wert setzen, zumindest nicht bei den zwei Daten: 01.03.xxxx 00:01:00 und 01.01.xxxx 00:01:00
Wie gesagt, alles andere funktioniert richtig.
Wenn jemand Interesse an dem Testprogramm hat, mit dem ich die Metadaten geschrieben habe, kann ich es noch hochladen.
Gruß Knobbi38
Hallo Ulli,
es wäre nett, wenn Du das Testprogramm hochladen würdest. ggf auch einfach als PM.
Danke
Holger
Hallo Holger,
kein Problem.
Gruß
Ulrich
Hallo Ulli
Danke, das ist ja der gleiche weg den ich auch so vorgeschlagen habe. Aber was hälst Du von zurückschreiben (ist natürlich aufwendiger). Ich finde Deine Idee hier für Jörg mit die MetaDaten in den Dateinamen einzubauen viel eleganter und einfachen.
Gruß
Holger
Das mit dem letzten Zugriffsdatum ist ja für Jörg irrelevant, insofern sollte er es einfach ausprobieren. Wenn das per API oder FSO nicht funktioniert, würde ich die Metadaten in den Dateinamen einbauen und eine kleine Kopierroutine erstellen, welche die notwendigen Änderungen vornimmt. Das geht mit dem FSO sicherlich viel einfacher, als mit der API. Für eine Batchverarbeitung könnte an auch an ein PowerShell-Script in Betracht ziehen, z.B. wenn es um ganze Verzeichnisstrukturen geht.
Gruß
Ulrich
Zitat von: Knobbi38 am Juni 02, 2026, 13:36:37Ich habe dazu mal die KI befragt und nach hartnäckigem "Nachbohren" habe ich dann auch eine technisch akzeptable Antwort bekommen
War die Antwort denn korrekt? Also, gibt es offizielle Quellen von Microsoft die diesen Sachverhalt so bestätigen?
Ich finde in der Dokumentation von Microsoft Warnungen, dass
LastAccessTime ungenau ist und wegen des hohen Ressourcenbedarfs standardmäßig deaktiviert ist. Aber Hinweise auf konkrete Probleme mit dem 01.03.xxxx 00:01:00 und 01.01.xxxx 00:01:00 habe ich nicht gefunden.
Ich habe dein Beispiel ausprobiert und keine Probleme feststellen können.
Hallo Phil,
ich habe mehrere Anläufe unternommen und verschiedene Dinge ausprobiert. Klar ist, dass NTFS immer UTC Zeit für diese Zeitangaben verwendet. Das Problem ist nun, dass beim Letzten Zugriffsdatum irgend etwas verloren geht, möglicherweise aus Performancegründen. Wie auch immer, spielt anschließend die Umrechnung von lokaler Zeitangabe in UTC Zeit dann nicht mehr mit. Wenn man von #01.03.2026 12:01:00 AM# (CEST) zwei Stunden abzieht, kommt man genau zu dem Phänomen, dass im Explorer bei den Eigenschaften die Zeit falsch ist, "28. Feb. ....". Sie wird nicht für die Anzeige einfach falsch zurückgerechnet, sondern wenn man das per API ausliest, kann man mit dem Debugger die einzelnen Schritte ja mitverfolgen. Genauso dann das Problem mit dem Datum 01.01.2026, so wie es Jörg auch beschrieben hat.
Ich kann die Angaben natürlich nicht mit offiziellen Dokumenten von Microsoft verifizieren. Alle Hinweise, die mir die KI bezüglich des Problems gegeben hat, konnte ich jedoch nachvollziehen. Deshalb nehme ich jetzt an, dass diese erst einmal stimmen, es sei denn, jemand zeigt mir, dass es nicht so ist.
Wenn man sich außerdem die anderen Suchergebnisse im Internet ansieht, beschreiben die ähnliche Phänomene. Du kannst ja mal mit dem Stichwort: "Time Zone Discrepancies and the 'One Hour' Bug" suchen, was aber nur einen Teil des Problems beschreibt, LastAccessTimestamp ist noch ein anderes.
Gruß
Ulrich
Nachtrag:
Das sollte man auch noch kontrollieren:
https://www.tenforums.com/tutorials/139015-enable-disable-ntfs-last-access-time-stamp-updates-windows-10-a.html (https://www.tenforums.com/tutorials/139015-enable-disable-ntfs-last-access-time-stamp-updates-windows-10-a.html)
Zitat von: Knobbi38 am Juni 03, 2026, 13:07:37Wenn man von #01.03.2026 12:01:00 AM# (CEST) zwei Stunden abzieht, kommt man genau zu dem Phänomen, dass im Explorer bei den Eigenschaften die Zeit falsch ist, "28. Feb. ....".
? Aber der 28.02.2026 22:01 wäre doch richtig wenn man 2 Stunden abzieht.
Da der Explorer aber die lokale Zeit zeigen soll, ist es doch korrekt, dass er die 2 Stunden *nicht* abzieht.
Sorry, ich sehe hier scheinbar das Problem nicht.
2026-06-03_15h29_36.png
Ich habe TesteMetadatenVerschiebung zweimal ausgeführt. Erst für den 01.03. dann für den 01.01.:
==================================================
1. METADATEN VOR DEM UPDATE (LOKALZEIT):
Erstellungsdatum: 03.06.2026 15:25:26
Änderungsdatum: 27.11.2018 23:44:58
Letzter Zugriff: 03.06.2026 15:25:26
--------------------------------------------------
2. METADATEN NACH DEM UPDATE (LOKALZEIT):
Erstellungsdatum: 01.03.2026 00:01:00
Änderungsdatum: 01.03.2026 00:01:00
Letzter Zugriff: 01.03.2026 00:01:00
==================================================
==================================================
1. METADATEN VOR DEM UPDATE (LOKALZEIT):
Erstellungsdatum: 01.03.2026 00:01:00
Änderungsdatum: 01.03.2026 00:01:00
Letzter Zugriff: 01.03.2026 00:01:00
--------------------------------------------------
2. METADATEN NACH DEM UPDATE (LOKALZEIT):
Erstellungsdatum: 01.01.2026 00:01:00
Änderungsdatum: 01.01.2026 00:01:00
Letzter Zugriff: 01.01.2026 00:01:00
==================================================
Hallo Phil,
es scheint von mehreren Faktoren abhängig zu sein - welche das sind kann ich nicht mit Bestimmtheit sagen, aber auch die Treiber scheinen daran beteiligt zu sein.
So sieht das bei mir aus:
Dateivergleich_1.png
==================================================
1. METADATEN VOR DEM UPDATE (LOKALZEIT):
Erstellungsdatum: 08.03.2026 11:45:03
Änderungsdatum: 08.03.2026 11:45:04
Letzter Zugriff: 31.05.2026
--------------------------------------------------
2. METADATEN NACH DEM UPDATE (LOKALZEIT):
Erstellungsdatum: 01.03.2026 00:01:00
Änderungsdatum: 01.03.2026 00:01:00
Letzter Zugriff: 28.02.2026 23:00:00
==================================================
==================================================
1. METADATEN VOR DEM UPDATE (LOKALZEIT):
Erstellungsdatum: 01.03.2026 00:01:00
Änderungsdatum: 01.03.2026 00:01:00
Letzter Zugriff: 03.06.2026
--------------------------------------------------
2. METADATEN NACH DEM UPDATE (LOKALZEIT):
Erstellungsdatum: 01.01.2026 00:01:00
Änderungsdatum: 01.01.2026 00:01:00
Letzter Zugriff: 31.12.2025 23:00:00
==================================================
>fsutil behavior query disableLastAccess
DisableLastAccess = 2 (Vom System verwaltet, Updates für letzte Zugriffszeit ENABLED)
Man beachte die Uhrzeit bei "Letzter Zugriff". Das mach nicht wirklich Sinn.
Allerdings habe ich gerade bemerkt, das andere Laufwerke bei mir die gleichen Ergebnisse anzeigen, wie in deinem Beispiel. Das Verhalten ist für mich nicht plausibel.
Gruß
Ulrich