ErgänzungenDer Bug wird durch die Windows Utility
Compressed Folders und das falsche Änderungsdatum der extrahierten Dateien hervorgerufen.
Der genaue Ablauf ist aber komplizierter, als ich ursprünglich angenommen hatte. Wenn man einfach ein beliebiges Archiv mit Compressed Folders entpackt, dann stimmt das Änderungsdatum der extrahierten Dateien noch. Anscheinend sind auch nur Windows XP, Server 2003 und Vista betroffen. Das vollständige Bild enthält die folgenden Schritte:
- Das Archiv wsusoffline115.zip wird mit dem Internet Explorer heruntergeladen. Die Datei wird dabei mit einem alternativen Datenstrom vom Typ Zone.Identifier gekennzeichnet. Der Inhalt des Datenstroms ist:
- Code: Select all
[ZoneTransfer]
ZoneID=3
- Das Archiv wird mit der Windows Utility Compressed Folders entpackt, indem Alle extrahieren... aus dem Kontextmenü gewählt wird. Dabei wird der alternative Datenstrom in alle extrahierten Dateien kopiert. Gleichzeitig wird das Änderungsdatum der Dateien auf das aktuelle Datum gesetzt.
Wenn man nun den UpdateGenerator.exe öffnet, bekommt man eine Sicherheitsabfrage, ob man die Datei auch wirklich ausführen möchte. Auch für alle anderen Dateien bekommt man eine Sicherheitswarnung beim Öffnen. Dies stört den automatischen Ablauf der Skripte in WSUS Offline Update.
- Die alternativen Datenströme werden deshalb mit Sysinternals Streams wieder entfernt. Dies wurde mit der Version 10.0.1 vom 10.09.2015 eingeführt:
- DownloadUpdates.cmd script will now delete NTFS alternate data streams from new or updated script files (Thanks to "blackerking", "boco" and "aker")
Streams ändert das Änderungsdatum der Dateien aber nicht erneut.
Man kann das auch mit einem Archiv nachvollziehen, das noch
keinen alternativen Datenstrom enthält. Dazu gibt man in der Eingabeaufforderung ein:
- Code: Select all
notepad wsusoffline115.zip:Zone.Identifier
Das öffnet Notepad.exe mit einem leeren, alternativen Datenstrom. Als Inhalt gibt man ein:
- Code: Select all
[ZoneTransfer]<CR><LF>
ZoneID=3<CR><LF>
<CR><LF> steht hier für die Zeilenenden unter Windows. Die Datei muss also mit einer Leerzeile enden. Die Gesamtlänge des alternativen Datenstroms muss 26 Byte betragen.
Dann wird die Datei mit Compressed Folders entpackt wie beschrieben.
WorkaroundEs gibt auch einen einfachen Workaround: Nach dem Download des Archivs muss man
erst den Zone.Identifier löschen,
bevor man es entpackt. Dazu öffnet man das Eigenschaften-Fenster für das Archiv. Unten steht der Hinweis:
"Sicherheit: Die Datei stammt von einem anderen Computer. Der Zugriff wurde aus Sicherheitsgründen eventuell geblockt."
Daneben steht die Taste
Zulassen, mit der man den Zone.Identifier löschen und damit die Sicherheits-Warnungen verhindern kann. Auch die extrahierten Dateien haben wieder das richtige Änderungsdatum.
ReferenzenWhen you extract a compressed file that you downloaded from the Internet, the file's modified date changes to the date that you extracted it
https://support.microsoft.com/en-us/hel ... the-internWhy don’t the file timestamps on an extracted file match the ones stored in the ZIP file?
https://blogs.msdn.microsoft.com/oldnew ... 0/?p=10743How to Unblock Files Downloaded from Internet?
https://www.winhelponline.com/blog/bulk ... -internet/7-Zip kopiert den Zone-Identifier dagegen nicht in die extrahierten Dateien, obwohl manche das für einen Bug halten. Es ist im Grunde genommen aber egal, wenn nur das Änderungsdatum der extrahierten Dateien erhalten bleibt:
Bug #1649 Zone Identifiers of unzipped files.
https://sourceforge.net/p/sevenzip/bugs/1649/