Verändert Windows 11 23H2 (Build 22631.4317) das Dateidatum beim Kopieren von Dateien? Ein Blog-Leser ist mir einem entsprechenden Hinweis an mich herangetreten. Mein Versuch, das zu verifizieren, war aber nicht erfolgreich. Daher stelle ich das Thema mal hier im Blog ein, vielleicht können Leser das verifizieren.
Problembeschreibung des Lesers
Michael V. hat mich zum 21. Oktober 2024 per Mail kontaktiert und sein Problem, zu dem er bisher nichts im Internet finden konnte, beschrieben.
Er hat unter Windows 11 23H2 Build 22631.4317 eine Datei im Netzwerkshare auf einen anderen Ordner kopiert. Dazu hat er den Windows Explorer und die Befehle Datei kopieren/einfügen benutzt.
Dabei stellte er „mit Entsetzen“ fest, das er das Erstellt, Geändert Datum der betreffenden Datei auf die aktuelle Uhrzeit setzt. Für den Leser ist das „eine kleine Katastrophe“, da er oftmals mit Dokumenten arbeite und diese im Windows Explorer nach Datum sortiere.
Der Leser hat dann die Gegenprobe gemacht und schreibt: Bei Windows 11 22H2 war das Problem noch nicht da. Ebenso tritt es aktuell nicht bei Windows 10 auf. Kopiert man dort Dateien auf der lokalen Festplatte bleibt das alte Datum bestehen.
Es betrifft also nur Netzwerkdateien die innerhalb des Netzwerk-Share kopiert werden. Eine Datei aus dem Netzwerk mit dem Ziel lokale Festplatte macht auch keine Probleme.
Er fragte mich, ob ich darüber Informationen habe, was ich aber verneinen musste. Bisher habe ich das Verhalten bei kurzen Tests auch noch nicht nachstellen können. Der Leser schrieb mir, dass er das Problem an 4 PCs reproduzieren kann. Jemand aus der Leserschaft, der das bestätigen kann?
Ähnliche Artikel:
Windows 11 24H verfügbar (1. Oktober 2024)
Windows 11 24H2: Achtung, geänderter Default für Standby
Windows 11 24H2: Zahlreiche Show-Stopper und bekannte Bugs
Windows 11 24H2: Böse Probleme nach dem Upgrade
Windows 11 24H2: Lese-/Schreibgeschwindigkeit bei SMB extrem langsam?
Windows 11 24H2: Aktivierung beim Upgrade verloren?
Windows: DirectAccess abgekündigt; Always On VPN empfohlen
Windows 11 24H2: Probleme mit VPN-Verbindungen, Direct Access …
Windows 11 24H2: Recall nicht deinstallierbar …
Probleme mit Windows 11 24H2/Windows Server 2025
Windows 11 24H2: Achtung, Kiosk-Mode wohl kaputt
Windows 11 24H2: Microsoft bestätigt falsche Anzeige in Datenträgerbereinigung
Windows 11 24H2: Apps reagieren bei Verwendung der Kamera nicht mehr
Windows 11 24H2: Vorsicht bei ASUS-Geräten – Installation scheitert
Windows 11 24H2: Voicemeeter-App stürzt mit Fehler ab
Windows 11 23H2 (22631.4317) verändert Datei-Datum beim Kopieren
Windows 11: Recall kommt doch später …
Mir ist so ein ähnliches Phänomen – allerdings NUR bei NEU erstellten Ordnern – beim „Änderungsdatum“ des Ordners beim Kopieren auf einen USB-Stick (>> tägl. Datensicherung) schon vor rund einem Jahr aufgefallen. Das Datum der Dateien, die im Ordner enthalten sind, war bisher immer korrekt, wurde also genau gleich wie beim Original kopiert. Auch wird der kopierte und (dann) falsch datierte Ordner bei der nächsten Sicherung wieder auf das richtige (Original-)Datum „korrigiert“. Es sind also wirklich nur immer neu erstellte Ordner beim ersten Sichern betroffen. Und dies auch nur temporär bis zur nächsten Sicherung. Da ich immer nur veränderte Dateien/Ordner sichern lasse, wird also das vermeintlich falsche Ordner-Datum von Windows am nächsten Tag als „Veränderung“ erkannt und berichtigt. Die zunächst falschen Datums- und Uhrzeitangaben bei den Ordnern, sind teilweise echt krude und werden oft Monate und/oder sogar Jahre falsch angezeigt. Ein evtl. Schema bei der Falschbezeichnung konnte ich bisher nicht erkennen … Hat mich bisher auch nicht sonderlich beschäftigt, da eben zum Glück nicht die Dateien direkt betroffen sind, sondern „nur“ die Ordner – und diese eben 24 Stunden später wieder berichtigt werden und dann zukünftig auch so bleiben. Aber interessant ist es nun allemal, dass auch noch andere – wenn auch in anderer Konstellation – davon betroffen zu sein scheinen …
Gerade getestet am Netzwerk mit Windows 11 24H2, Erstelltdatum wird geändert. Änderungsdatum bleibt gleich.
Gleiches Verhalten von Lokal zu Lokal und Netzwerk zu lokal.
Macht ja auch Sinn, die Datei wird ja neu erstellt (als Kopie). Beim Ausschneiden/Einfügen bleiben beide entsprechend Zeitstempel erhalten.
Hallo ich war der Einsender und kann noch dazu etwas ergänzen :
Wo sich die Dateien als Share befinden, ob auf einem Windows 10, 2022 Server, auf Linux Ubuntu Server oder einer Satbox mit Enigma2 ist egal, somit kommt das Problem vom Client.
Rechte Maustaste auf der Datei im Netzwerk Share, kopieren und wieder einfügen, gleicher Ordner oder einen anderen Ordner im Share.
Windows 10 Version 22H2 Build 19045.3636, kein Problem, Änderungs Datum richtig.
Windows 11 Version 22h2 Build 22621.3296, kein Problem, Änderungs Datum richtig.
M:\>dir
20.11.2018 11:33 57.525 suite-einstellungen01 – Kopie.jpg
20.11.2018 11:33 57.525 suite-einstellungen01.jpg
20.11.2018 11:34 60.427 suite-einstellungen02.jpg
20.11.2018 11:34 54.617 suite-einstellungen03.jpg
20.11.2018 11:35 51.226 suite-einstellungen04.jpg
20.11.2018 11:35 43.220 suite-einstellungen05.jpg
Windows 11 Version 22h2 Build 22621.4317, Problem da, alle Datumsangaben auf aktuelle Kopierzeit
Windows 11 Version 23h2 Build 22631.4317, Problem da, alle Datumsangaben auf aktuelle Kopierzeit
M:\>dir
25.10.2024 07:30 57.525 suite-einstellungen01 – Kopie.jpg
20.11.2018 11:33 57.525 suite-einstellungen01.jpg
20.11.2018 11:34 60.427 suite-einstellungen02.jpg
20.11.2018 11:34 54.617 suite-einstellungen03.jpg
20.11.2018 11:35 51.226 suite-einstellungen04.jpg
20.11.2018 11:35 43.220 suite-einstellungen05.jpg
Das Problem taucht wohl mit Build x.4317 auf.
Windows 11 schreibt durch einen Bug seit evtl. Februar, aber spätestens seit 11.Juni 2024 (KB5039212, Build 22621.3737 und 22631.3737) die „Zone ID information“ in den NTFS-„Alternate Data Streams“ (ADS) der Datei und das verändert dann das „Änderungsdatum“.
Das „Dateidatum“ im Artikel ist nicht eindeutig, denn es gibt mehrere Zeitstempel für Dateien.
Im Explorer kann man einstellen, welche Zeitstempel man sieht, „Ansicht“, „Details auswählen“,
[x] „Änderungsdatum“ („Date Modified“)
[x] „Erstelldatum“
[x] „Inhalt erstellt“
[x] „Letzter Zugriff“
etc
Beim Kopieren einer Datei ändern sich (Windows 7 als Referenz):
„Erstelldatum“ der Datei
„Letzter Zugriff“ der Datei
„Änderungsdatum“ des Ziel-Ordners
„Letzter Zugriff“ des Ziel-Ordners
„Änderungsdatum“ und „Inhalt erstellt“ der Datei bleiben gleich.
„Erstelldatum“ des Ziel-Ordners bleibt gleich, wenn er vorher bereits vorhanden war.
Zitat aus Artikel:
„Erstellt, Geändert Datum der betreffenden Datei auf die aktuelle Uhrzeit setzt“
Das wäre dann allerdings ein Bug, denn das „geändert Datum“ (= „Änderungsdatum“) soll gleich bleiben, also identisch mit der Quell-Datei.
Dass sich das „Erstelldatum“ der Datei ändert, ist hingegen normal, denn es wird eine neue Datei erzeugt.
Der „Total Commander“ zeigt nur das Änderungsdatum an und wenn Windows 11 das falsch ändert, dann funktionieren einige Vergleichsoperationen des Total Commanders nicht mehr korrekt („Markieren“, „Verzeichnisse vergleichen“).
In den Foren von Microsoft, bei SuperUser, github etc habe ich einige gleichlautende Fehlermeldungen gefunden.
Das Update KB5039212 vom 11.Juni 2024 scheint eine der Ursachen zu sein, weshalb sich auch das Änderungsdatum beim Kopieren (falsch) ändert.
Es gibt aber auch diese Fehlermeldungen vom Februar 2024, als es dieses Update noch nicht gab.
Im Microsoft-Answers-Forum steht eine passende Antwort:
„When you copy a file from a network share, the Zone ID information is written to the Alternate Data Streams (ADS), which causes the file date to be modified. This might be a bug in the recent Windows 11 builds. “
Workaround:
„However, there is a workaround. To prevent the ADS from being written, you can add the computer name that hosts the network share to the Local Intranet zone in IE Options.
To open IE Options, run „inetcpl.cpl“.
Click on the „Security“ tab, and click „Local Intranet“.
Click „Sites“, and click „Advanced“.
Add the computer name or the IP address of the computer that hosts the network share to the list.
Click OK, OK, to save your settings.“
Quellen:
1. Bugmeldung vom 17.Februar 2024:
answers[.]microsoft[.]com/en-us/windows/forum/all/file-explorer-and-date-createdmodified-change-when/e6ad833e-a134-4da8-a9e0-815c92eeecfa
2. Bugmeldung vom 21.Juni 2024:
answers[.]microsoft[.]com/en-us/windows/forum/all/date-modified-changes-on-copy-from-server-to-local/908c95ac-c75a-41d8-aa70-b08082b5f9e9
3. Bugmeldung vom 21.August 2024:
superuser[.]com/questions/1852879/how-to-stop-windows-from-changing-date-modified-when-copying-files-from-network
4.Bugmeldung bei github am 12.Juli 2024:
github[.]com/WinMerge/winmerge/issues/2375
5. Bugmeldung vom 12.Juni 2024 und Workaround im ersten Kommentar:
answers[.]microsoft[.]com/pl-pl/windows/forum/all/a-date-of-a-file-during-copying-files/1a45b29d-0474-4d54-82a5-7482d9a323dc
Weitere Ursache und zweiter Workaround (aus der Quelle 5, dort der 2. Kommentar):
The problem with changing the „Modified Date“ occurs when I copy from an untrusted network share.
We can obtain a solution similar to the above by modifying the file:
C:\\Windows\\System32\\drivers\\etc\\hosts
adding the mappings of IP addresses to host names.
Using the host name from the „hosts“ file. The system recognizes the network share as trusted and does not change the „Modification Date“ when copying files from this location.
###
Danke für deine Nachforschungs-Mühe!
Das erklärt nun so Einiges – und klärt zumindest „meinen Fehler“ bzgl. des Ordner-„Änderungsdatum“ weitestgehend auf …
Das Problem lässt sich einfach lösen, indem man TeraCopy nutzt:
https://www.codesector.com/teracopy
– Es lässt sich als Default Copy Handler festlegen, wird also automatisch bei Ctrl+C, V, etc. genutzt.
– Es kopiert nicht nur die Dateien, sondern prüft danach per Prüfsumme alle kopierten Dateien, ob sie korrekt kopiert wurden (hat mir schon so manche beschädigte Datei erspart)
– Es kopiert multithreaded und mit höherer Performance als unter Windows (11).
– last but not least :-) – es setzt SÄMTLICHE Eigenschaften von Ordnern und Dateien am Ende exakt so wie die Quelldatei.
– kopiert man während eines laufenden Kopiervorgangs weitere Dateien „dazu“, reiht es diese Dateien intelligent ein. Ist Quelle und Ziel identisch mit dem aktuell laufenden Kopiervorgang, wird der aktuelle Copy-Job erweitert. Weichen diese ab, queued er st in einem zweiten Tab, der jederzeit manuell parallel gestartet werden kann oder pausiert. Einfach mega :-)
Nur zu empfehlen. Die Pro-Version ist nicht nötig, die Free-Version kann schon alles. Hab die Pro-Version aber für 15€ bekommen, das unterstütze ich gerne. Unfassbar gutes Tool.
Tolle Eigenwerbung…
Tolles Produkt, for Free, wie man das als Eigenwerbung sehen kann, nunja…
Für Dateioperationen bei denen es auf ein korrekte Erstellung- und Änderungsdatum und andere Dateiattribute ankommt, verwende ich immer Multicommander oder Robocopy, wobei aber jeder andere Filecommander ebenfalls entsprechende Optionen anbietet.
Mit dem Windows Explorer habe ich schon öfters die Erfahrung gemacht das beim Kopieren, Verschieben ect. es mit den Datum-Atrributen nicht so genau genommen wird, vor allem bei Netzwerkfreigaben.
Ich habe ein ähnlich seltsames Verhalten.
Wenn ich eine Datei umbenenne in .eml ändert sich das Änderungsdatum entweder sofort oder beim Rechtsklick um z.B. öffnen mit… auszuwählen. Bei anderen Erweiterungen passiert nix.
Getestet auf Win10, Server 2019 und Server2016 via RDP
Der 16er ist quasi „nackt“ keine Anwendungsprogramme und nur Defender. Aber auch nach Deaktivierung des Echtzeitschutzes aktualisiert sich das Änderungsdatum.