Vermeiden von File integrity verification failures

Vermeiden von File integrity verification failures

Postby hbuhrmester » 06.12.2015, 14:38

Zusammenfassung
Eine Ursache für den Fehler File Integrity Verification Failure wird diskutiert. Eine Lösung wird vorgeschlagen und ein kleiner Trick vorgestellt, wie man diesen Fehler selber vermeiden kann.

Einführung
Vor jedem Download wird die Integrität der bereits vorhandenen Dateien überprüft. Dazu werden die einzelnen Unterverzeichnisse des client-Ordners mit hashdeep auf Änderungen überprüft. Manchmal findet hashdeep eine Änderung. Da der Audit-Modus von hashdeep sehr strikt ist, führt das zu der Meldung File Integrity Verification Failure.

Als Ursache gelten Download-Fehler beim vorherigen Aufruf des Skripts. Dies tritt besonders häufig bei den Virusdefinitionen auf, da diese Dateien sich ständig ändern. Doch das ist nicht die eigentliche Ursache für einen File Integrity Verification Failure: Wenn in einen Ordner zum Beispiel 100 Dateien heruntergeladen werden sollen, und ein einzelner Download schlägt fehl, dann erstellt hashdeep einfach eine Prüfsummendatei für die restlichen 99 Dateien. Beim nächsten Aufruf findet hashdeep eine Prüfsummendatei mit 99 Einträgen und einen Ordner mit 99 Dateien — das verursacht keinen Fehler.

Die eigentliche Ursache
Die eigentliche Ursache liegt darin, dass hashdeep manchmal leere Dateien produziert, wenn es im angegebenen Ordner überhaupt keine Dateien findet.

Oder genauer ausgedrückt: hashdeep produziert keine Ausgabe, wenn es keine Eingabedateien findet. Die Ausgabeumlenkung:

DownloadUpdates.cmd, Version 10.2.1, Zeile 1002
Code: Select all
..\bin\%HASHDEEP_EXE% -c md5,sha1,sha256 -l -r ..\wddefs >hashes-wddefs.txt


produziert dann aber trotzdem eine leere Prüfsummendatei.

hashdeep gibt dabei keinen Fehlercode aus, wie man zum Beispiel in einer Linux-Shell nachvollziehen kann:

Code: Select all
~/tmp$ mkdir empty_folder
~/tmp$ hashdeep -r -l empty_folder/ > hashes-empty_folder.txt
~/tmp$ echo $?
0
~/tmp$ cat hashes-empty_folder.txt
~/tmp$



Beim nächsten Lauf verursacht die Überprüfung des Ordners mit einer leeren Prüfsummendatei aber einen Fehler:

Code: Select all
~/tmp$ hashdeep -a -v -v -r -l -k hashes-empty_folder.txt empty_folder/
hashdeep: hashes-empty_folder.txt: Unable to identify file format
hashdeep: Unable to load any matching files.
Try `hashdeep -h` for more information.
~/tmp$ echo $?
64
~/tmp$


Dieser Fehler wird vom Skript DownloadUpdates.cmd als File Integrity Verification Failure ausgegeben, und das Skript stoppt anschliessend.

Diese Situation tritt besonders häuft beim Download der Windows Defender Definition files auf, da es für diesen Download nur jeweils eine Datei für jede Architektur gibt, und der Download dieser einzelnen Datei schlägt häufig fehl. Tatsächlich scheint der Fehler File Integrity Verification Failure typischerweise an der Stelle aufzutreten, an der die vorhandenen Dateien im Ordner client/wddefs überprüft werden sollen.

Dies wurde zum Beispiel hier beobachtet:

viewtopic.php?f=3&t=5217#p17052

Die Lösung
Das Skript DownloadUpdates.cmd sollte die Erstellung von leeren hashdeep-Dateien überprüfen. Tatsächlich gibt es solche Tests bereits an zwei Stellen:

DownloadUpdates.cmd, Version 10.2.1, Zeile 1064
Code: Select all
for %%i in (..\client\md\hashes-%1-%2.txt) do if %%~zi==0 del %%i


DownloadUpdates.cmd, Version 10.2.1, Zeilen 1522 - 1529
Code: Select all
for %%i in (..\client\md\hashes-%1-%2.txt) do (
  if %%~zi==0 (
del %%i
echo %DATE% %TIME% - Info: Deleted zero size integrity database for %1 %2>>%DOWNLOAD_LOGFILE%
  ) else (
echo %DATE% %TIME% - Info: Created integrity database for %1 %2>>%DOWNLOAD_LOGFILE%
  )
)


Damit werden aber nur die Prüfsummendateien für Windows- und Office-Updates überprüft. Bei den verschiedenen optionalen Downloads fehlen diese Tests.

Diese beiden Tests sollten auch in die optionalen Downloads eingebaut werden. Wenn man das nur für den Ordner client/wddefs macht, sollte das die Häufigkeit der File Integrity Verification Failures deutlich reduzieren.

Ein Workaround
Ein kleiner Workaround für diesen Fehler könnte sein, eine beliebige Datei in den Ordner client/wddefs zu legen. Dieser Ordner wird bei der Verifizierung der Dateisignaturen mit Sysinternals Sigcheck nicht überprüft; nur die beiden Unterordner x64-glb und x86-glb werden überprüft. Eine Datei an dieser Stelle wird deshalb nicht gelöscht.

Die Prüfsummendateien werden aber direkt für den Ordner client/wddefs erstellt. Wenn man hier eine beliebige Datei platziert, sollte das die Bildung von leeren Prüfsummendateien verhindern. Ein paar Absätze aus dem bekannten Lorem Ipsum genügen:

https://de.wikipedia.org/wiki/Lorem_ipsum

Image

Eine vorhandene Prüfsummendatei wsusoffline/client/md/hashes-wddefs.txt muss aber einmal gelöscht werden, damit der Ordnerinhalt und die Prüfsummendatei beim nächsten Lauf wieder synchronisiert werden.

TL;DR
Eine beliebige Datei im Verzeichnis wsusoffline/client/wddefs verhindert die Erstellung von leeren Prüfsummendateien und beseitigt damit eine der Hauptursachen für den Fehler File Integrity Verification Failure.
Eine vorhandene Datei wsusoffline/client/md/hashes-wddefs.txt muss einmal gelöscht werden.
Attachments
Lorem-ipsum.png
(27.62 KiB) Not downloaded yet
hbuhrmester
 
Posts: 525
Joined: 11.10.2013, 20:59

Re: Vermeiden von File integrity verification failures

Postby WSUSUpdateAdmin » 19.01.2016, 16:10

Moin!

Vielen Dank, Hartmut! :)

Krankheitsbedingt habe ich diesen Thread leider erst jetzt gesehen, den Vorschlag, die leeren Prüfsummendateien konsequent überall zu löschen, aber gleich umgesetzt (r719).

Viele Grüße,
Torsten
WSUSUpdateAdmin
Administrator
 
Posts: 2245
Joined: 07.07.2009, 14:38

Re: Vermeiden von File integrity verification failures

Postby hbuhrmester » 23.01.2016, 18:30

File Integrity Verification Error aufgrund von fehlenden Benutzerrechten

Eine weitere möglichte Ursache für einen File Integrity Verification Error sind fehlende Benutzerrechte.

Wenn das Skript DownloadUpdates.cmd nicht die nötigen Rechte hat, um Dateien zu ändern oder umzubenennen, dann wird es nicht richtig funktionieren. Doch die Fehler zeigen sich keineswegs sofort, sondern erst beim zweiten Versuch. Dann werden als erste Unregelmäßigkeiten File Integrity Verification Errors bei der Überprüfung der Ordner client/cpp, client/msse und client/wle gemeldet.

Das Problem bei diesen Ordnern ist, dass die vorhandenen Dateien nicht umbenannt werden können. Das ist normalerweise die Voraussetzung dafür, dass die Timestamping-Option von wget funktioniert.

Beim ersten Download lädt wget deshalb alle Dateien neu herunter, da die Dateinanmen, Dateigrößen und Änderungsdaten auf dem Server jeweils unterschiedlich sind. Die heruntergeladenen Dateien können wiederum nicht umbenannt werden, sodass am Ende ein bis vier Dateien doppelt vorhanden sind. Die Prüfsummendatei kann natürlich auch nicht gelöscht und neu geschrieben werden.

Das bleibt aber zunächst unbemerkt, da die Fehlermeldungen "Zugriff verweigert" nur im Fenster der Eingabeaufforderung erscheinen. Sie werden nicht abgefangen und erscheinen auch nicht im Download-Log.

Beim zweiten Versuch wird ein File Integrity Verification Error gemeldet, da der Inhalt des Ordners nicht mehr mit der Prüfsummendatei übereinstimmt. Die Ausgabe von hashdeep zeigt, dass eine oder mehrere Dateien doppelt vorhanden sind ("moved from"). Jetzt taucht auch eine Fehlermeldung in der Logdatei auf.

Man kann dies am besten nachvollziehen, wenn man vor dem Label :SkipCPP eine "pause" einsetzt, sodass das Skript an dieser Stelle stoppt. Beim ersten Versuch bekommt man diese Meldungen im Fenster der Eingabeaufforderung:

Code: Select all
Verifying integrity of C++ Runtime Libraries' installation files...
hashdeep.exe: Audit passed
   Input files examined: 0
  Known files expecting: 0
          Files matched: 12
Files partially matched: 0
            Files moved: 0
        New files found: 0
  Known files not found: 0
C:\wsusoffline\client\md\hashes-cpp.txt
Zugriff verweigert
Downloading/validating C++ Runtime Libraries' installation files...
Renaming file ..\client\cpp\vcredist2005_x64.exe to vcredist_x64.EXE...
Zugriff verweigert
--2016-01-23 11:31:46--  http://download.microsoft.com/download/8/B/4/8B42259F-5D70-43F4-AC2E-4B208FD8D66A/vcredist_x64.EXE
Connecting to 192.168.2.101:3128... connected.
Proxy request sent, awaiting response... 200 OK
Length: 3175832 (3.0M) [application/octet-stream]
Saving to: `../client/cpp/vcredist_x64.EXE'

100%[======================================================================================================================>] 3,175,832    691K/s   in 4.6s

2016-01-23 11:31:54 (668 KB/s) - `../client/cpp/vcredist_x64.EXE' saved [3175832/3175832]

Renaming file ..\client\cpp\vcredist_x64.EXE to vcredist2005_x64.exe...
Dateiname existiert bereits, oder die Datei
konnte nicht gefunden werden.
Renaming file ..\client\cpp\vcredist2008_x64.exe to vcredist_x64.exe...
Zugriff verweigert
--2016-01-23 11:31:54--  http://download.microsoft.com/download/5/D/8/5D8C65CB-C849-4025-8E95-C3966CAFD8AE/vcredist_x64.exe
Connecting to 192.168.2.101:3128... connected.
Proxy request sent, awaiting response... 200 OK
Length: 5207896 (5.0M) [application/octet-stream]
Saving to: `../client/cpp/vcredist_x64.exe'

100%[======================================================================================================================>] 5,207,896    687K/s   in 7.5s

2016-01-23 11:32:02 (676 KB/s) - `../client/cpp/vcredist_x64.exe' saved [5207896/5207896]

Renaming file ..\client\cpp\vcredist_x64.exe to vcredist2008_x64.exe...
Dateiname existiert bereits, oder die Datei
konnte nicht gefunden werden.

[ weitere 10 Downloads... ]

Cleaning up client directory for C++ Runtime Libraries...
Verifying digital file signatures for C++ Runtime Libraries' installation files...
Creating integrity database for C++ Runtime Libraries' installation files...
Zugriff verweigert
Drücken Sie eine beliebige Taste . . .


Das Skript wurde durch die eingesetzte Anweisung "pause" am Label :SkipCPP abgebrochen. Das unveränderte Skript würde einfach weiterlaufen.

Der Stand ist nun:

  • Im Ordner client/cpp gibt es 16 Dateien, darunter vier neue Dateien: VC_redist.x64.exe, VC_redist.x86.exe, vcredist_x64.exe und vcredist_x86.exe
  • Die hashdeep-Datei hashes-cpp.txt konnte nicht neu angelegt werden.
  • Im Download-Log gibt es trotzdem keine Anzeichen auf Fehler:

Code: Select all
23.01.2016 11:26:49,46 - Info: Starting WSUS Offline Update download (v. 10.3.2) for w100 glb
23.01.2016 11:26:49,47 - Info: Option /includedotnet detected
23.01.2016 11:26:49,51 - Info: Option /verify detected
23.01.2016 11:26:49,54 - Info: Option /exitonerror detected
23.01.2016 11:26:49,57 - Info: Option /proxy detected
23.01.2016 11:26:50,00 - Info: Set time zone to LOC-1:00
23.01.2016 11:26:50,65 - Info: Updated static download definitions
23.01.2016 11:26:50,79 - Info: Downloaded/validated mkisofs tool
23.01.2016 11:26:51,25 - Info: Verified integrity of Windows Update Agent installation and catalog files
23.01.2016 11:27:11,78 - Info: Downloaded/validated most recent Windows Update Agent installation and catalog files
23.01.2016 11:27:11,78 - Info: Verified digital file signatures of Windows Update Agent installation and catalog files
23.01.2016 11:27:11,78 - Info: Created integrity database for Windows Update Agent installation and catalog files
23.01.2016 11:28:11,00 - Info: Verified integrity of .NET Frameworks' installation files
23.01.2016 11:28:35,20 - Info: Downloaded/validated installation files for .NET Frameworks 3.5 SP1 and 4.x
23.01.2016 11:28:35,25 - Info: Verified integrity of existing updates for dotnet x86-glb
23.01.2016 11:28:40,21 - Info: Determined static update urls for dotnet x86-glb
23.01.2016 11:28:45,72 - Info: Found valid list of superseded updates
23.01.2016 11:29:42,28 - Info: Determined dynamic update urls for dotnet x86-glb
23.01.2016 11:29:44,77 - Info: Downloaded/validated 1 statically defined updates for dotnet x86-glb
23.01.2016 11:29:47,28 - Info: Downloaded/validated 11 dynamically determined updates for dotnet x86-glb
23.01.2016 11:29:48,41 - Info: Cleaned up client directory for dotnet x86-glb
23.01.2016 11:29:48,42 - Info: Removed NTFS alternate data streams for dotnet x86-glb
23.01.2016 11:30:16,74 - Info: Verified digital file signatures for dotnet x86-glb
23.01.2016 11:30:30,39 - Info: Created integrity database for dotnet x86-glb
23.01.2016 11:30:30,72 - Info: Cleaned up client directory for .NET Frameworks 3.5 SP1 and 4.x
23.01.2016 11:30:30,73 - Info: Verified digital file signatures for .NET Frameworks' installation files
23.01.2016 11:30:30,73 - Info: Created integrity database for .NET Frameworks' installation files
23.01.2016 11:31:38,39 - Info: Verified integrity of C++ Runtime Libraries' installation files
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\vcredist2005_x64.exe to vcredist_x64.EXE
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\vcredist_x64.EXE to vcredist2005_x64.exe
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\vcredist2008_x64.exe to vcredist_x64.exe
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\vcredist_x64.exe to vcredist2008_x64.exe
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\vcredist2010_x64.exe to vcredist_x64.exe
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\vcredist_x64.exe to vcredist2010_x64.exe
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\vcredist2012_x64.exe to vcredist_x64.exe
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\vcredist_x64.exe to vcredist2012_x64.exe
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\vcredist2013_x64.exe to vcredist_x64.exe
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\vcredist_x64.exe to vcredist2013_x64.exe
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\vcredist2015_x64.exe to VC_redist.x64.exe
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\VC_redist.x64.exe to vcredist2015_x64.exe
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\vcredist2005_x86.exe to vcredist_x86.EXE
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\vcredist_x86.EXE to vcredist2005_x86.exe
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\vcredist2008_x86.exe to vcredist_x86.exe
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\vcredist_x86.exe to vcredist2008_x86.exe
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\vcredist2010_x86.exe to vcredist_x86.exe
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\vcredist_x86.exe to vcredist2010_x86.exe
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\vcredist2012_x86.exe to vcredist_x86.exe
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\vcredist_x86.exe to vcredist2012_x86.exe
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\vcredist2013_x86.exe to vcredist_x86.exe
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\vcredist_x86.exe to vcredist2013_x86.exe
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\vcredist2015_x86.exe to VC_redist.x86.exe
23.01.2016 11:31:46,43 - Info: Renamed file ..\client\cpp\VC_redist.x86.exe to vcredist2015_x86.exe
23.01.2016 11:34:39,15 - Info: Downloaded/validated C++ Runtime Libraries' installation files
23.01.2016 11:34:40,82 - Info: Cleaned up client directory for C++ Runtime Libraries
23.01.2016 11:34:40,82 - Info: Verified digital file signatures for C++ Runtime Libraries' installation files
23.01.2016 11:34:40,82 - Info: Created integrity database for C++ Runtime Libraries' installation files



Erst beim zweiten Versuch schlägt der Download fehl:

Code: Select all
Verifying integrity of C++ Runtime Libraries' installation files...
..\cpp\vcredist_x64.exe: Moved from ..\cpp\vcredist2013_x64.exe
..\cpp\vcredist_x86.exe: Moved from ..\cpp\vcredist2013_x86.exe
..\cpp\VC_redist.x64.exe: Moved from ..\cpp\vcredist2015_x64.exe
..\cpp\VC_redist.x86.exe: Moved from ..\cpp\vcredist2015_x86.exe
hashdeep.exe: Audit failed
   Input files examined: 0
  Known files expecting: 0
          Files matched: 12
Files partially matched: 0
            Files moved: 4
        New files found: 0
  Known files not found: 0

ERROR: File integrity verification failure.

Drücken Sie eine beliebige Taste . . .



Auch in der Logdatei taucht jetzt eine Fehlermeldung auf:

Code: Select all
23.01.2016 11:56:36,55 - Info: Starting WSUS Offline Update download (v. 10.3.2) for w100 glb
23.01.2016 11:56:36,56 - Info: Option /includedotnet detected
23.01.2016 11:56:36,60 - Info: Option /verify detected
23.01.2016 11:56:36,63 - Info: Option /exitonerror detected
23.01.2016 11:56:36,66 - Info: Option /proxy detected
23.01.2016 11:56:37,08 - Info: Set time zone to LOC-1:00
23.01.2016 11:56:37,40 - Info: Updated static download definitions
23.01.2016 11:56:37,45 - Info: Downloaded/validated mkisofs tool
23.01.2016 11:56:38,00 - Info: Verified integrity of Windows Update Agent installation and catalog files
23.01.2016 11:56:56,31 - Info: Downloaded/validated most recent Windows Update Agent installation and catalog files
23.01.2016 11:56:56,31 - Info: Verified digital file signatures of Windows Update Agent installation and catalog files
23.01.2016 11:56:56,31 - Info: Created integrity database for Windows Update Agent installation and catalog files
23.01.2016 11:57:20,68 - Info: Verified integrity of .NET Frameworks' installation files
23.01.2016 11:57:45,99 - Info: Downloaded/validated installation files for .NET Frameworks 3.5 SP1 and 4.x
23.01.2016 11:57:46,02 - Info: Verified integrity of existing updates for dotnet x86-glb
23.01.2016 11:57:50,73 - Info: Determined static update urls for dotnet x86-glb
23.01.2016 11:57:55,80 - Info: Found valid list of superseded updates
23.01.2016 11:58:53,33 - Info: Determined dynamic update urls for dotnet x86-glb
23.01.2016 11:58:57,39 - Info: Downloaded/validated 1 statically defined updates for dotnet x86-glb
23.01.2016 11:58:58,62 - Info: Downloaded/validated 11 dynamically determined updates for dotnet x86-glb
23.01.2016 11:58:59,54 - Info: Cleaned up client directory for dotnet x86-glb
23.01.2016 11:58:59,54 - Info: Removed NTFS alternate data streams for dotnet x86-glb
23.01.2016 11:59:08,95 - Info: Verified digital file signatures for dotnet x86-glb
23.01.2016 11:59:09,03 - Info: Created integrity database for dotnet x86-glb
23.01.2016 11:59:09,41 - Info: Cleaned up client directory for .NET Frameworks 3.5 SP1 and 4.x
23.01.2016 11:59:09,41 - Info: Verified digital file signatures for .NET Frameworks' installation files
23.01.2016 11:59:09,41 - Info: Created integrity database for .NET Frameworks' installation files
23.01.2016 11:59:49,51 - Error: File integrity verification failure



In einem anderen Thread konnte ich ähnliche Ergebnisse für die Ordner client/wle und client/msse beobachten:

viewtopic.php?f=3&t=5217&start=10#p17138
viewtopic.php?f=3&t=5217&start=20#p17146


Eigentlich wird beim Erstellen der Prüfsummendateien ja auf Fehler getestet:

Code: Select all
..\bin\%HASHDEEP_EXE% -c md5,sha1,sha256 -l -r ..\cpp >hashes-cpp.txt
if errorlevel 1 (
  popd
  echo Warning: Error creating integrity database ..\client\md\hashes-cpp.txt.
  echo %DATE% %TIME% - Warning: Error creating integrity database ..\client\md\hashes-cpp.txt>>%DOWNLOAD_LOGFILE%
) else (
  popd
  echo %DATE% %TIME% - Info: Created integrity database for C++ Runtime Libraries' installation files>>%DOWNLOAD_LOGFILE%
)



Es scheint aber, dass diese Ausgabeumlenkung nie zu einem Fehler führt; auch bei der Meldung Zugriff verweigert wird der errorlevel nicht erhöht. Vielleicht ist das ein Bug in hashdeep.

Man könnte hashdeep das Anlegen der Datei überlassen, indem die Ausgabedatei als Parameter an hashdeep übergeben wird:

Code: Select all
..\bin\%HASHDEEP_EXE% -c md5,sha1,sha256 -l -W hashes-cpp.txt -r ..\cpp
if errorlevel 1 (
  popd
  echo Warning: Error creating integrity database ..\client\md\hashes-cpp.txt.
  echo %DATE% %TIME% - Warning: Error creating integrity database ..\client\md\hashes-cpp.txt>>%DOWNLOAD_LOGFILE%
) else (
  popd
  echo %DATE% %TIME% - Info: Created integrity database for C++ Runtime Libraries' installation files>>%DOWNLOAD_LOGFILE%
)


Das hat den Nebeneffekt, dass die Dateien mit Unix-Zeilenenden geschrieben werden, während eine Ausgabeumlenkung die Ausgabe automatisch in DOS-Zeilenenden umwandelt. Aber hashdeep selber hat damit natürlich keine Probleme.

Bei unzureichenden Benutzerrechten bekommt man dann eine Fehlermeldung:

Code: Select all
Cleaning up client directory for C++ Runtime Libraries...
Verifying digital file signatures for C++ Runtime Libraries' installation files...
Creating integrity database for C++ Runtime Libraries' installation files...
hashdeep.exe: : Cannot open:
Warning: Error creating integrity database ..\client\md\hashes-cpp.txt.
Drücken Sie eine beliebige Taste . . .



Test der Benutzerrechte

Am besten kann man am Anfang des Skripts einen einfachen Test einbauen:

Code: Select all
rem *** Test for sufficient user privileges ***
ren ..\doc\history.txt history-renamed.txt
if errorlevel 1 echo Fehler beim Umbenennen der Datei history.txt, keine ausreichenden Benutzerrechte
ren ..\doc\history-renamed.txt history.txt
if errorlevel 1 echo Fehler beim Umbenennen der Datei history-renamed.txt, keine ausreichenden Benutzerrechte oder Datei existiert nicht


Das ist natürlich noch ausbaufähig, aber immerhin bekommt man von Anfang an eine passende Fehlermeldung:

Code: Select all
Starting WSUS Offline Update download (v. 10.3.2) for w100 glb...
Zugriff verweigert
Fehler beim Umbenennen der Datei history.txt, keine ausreichenden Benutzerrechte
Das System kann die angegebene Datei nicht finden.
Fehler beim Umbenennen der Datei history-renamed.txt, keine ausreichenden Benutzerrechte oder Datei existiert nicht



Weitere Vorschläge

Bei der Fehlersuche im Forum wäre es hilfreich, wenn die Leute auch den Text aus dem Fenster kopieren würden. Das geht mit dem Kontextmenü, wenn man also mit der rechten Maustaste in das Fenster klickt. Aber es ist wohl nicht sehr intuitiv. Dann könnte es helfen, einen entsprechenden Hinweis anzuzeigen, bevor das Fenster geschlossen wird.

Code: Select all
:Error
echo Note: To better help understanding this error, you can select and copy the last messages from this window using the context menu (right mouse click in the window).
pause
if "%EXIT_ERR%"=="1" (
  endlocal
  verify other 2>nul
  exit
) else (
  title %ComSpec%
  endlocal
  verify other 2>nul
  goto :eof
)
hbuhrmester
 
Posts: 525
Joined: 11.10.2013, 20:59

Re: Vermeiden von File integrity verification failures

Postby WSUSUpdateAdmin » 29.01.2016, 12:09

Moin Hartmut,

den Test der Benutzerrechte und den Hinweis bei einem Fehler habe ich jetzt eingebaut (r725).

Vielen Dank, viele Grüße
und ein schönes Wochenende,
Torsten
WSUSUpdateAdmin
Administrator
 
Posts: 2245
Joined: 07.07.2009, 14:38

Re: Vermeiden von File integrity verification failures

Postby hbuhrmester » 30.01.2016, 05:54

Hallo,

ich bin mir nicht sicher, ob der Test der Benutzerrechte so ausreicht.

In vielen Fällen ist es auch Benutzern mit eingeschränkten Rechten möglich, neue Dateien anzulegen: Wenn man den Ordner wsusoffline direkt auf C: oder auf einem externen Laufwerk entpackt, dann können alle Benutzer die vorhandenen Dateien und Ordner lesen, aber nur der Ersteller/Besitzer kann vorhandene Dateien ändern oder umbenennen.

Andere Benutzer können trotzdem neue Dateien anlegen und diese auch umbenennen — außer wenn es bereits vorhandene Dateien mit demselben Namen gibt.

Das war die Situation in den Verzeichnissen client/cpp, client/msse und client/wle: wget konnte neue Dateien in diese Verzeichnisse herunterladen. Sie konnten aber nicht umbenannt werden, weil die neuen Dateinamen mit den bereits vorhandenen Dateien kollidierten. Deshalb gab es am Ende mehrere Dateien doppelt.

Ein kleiner Test mit trunk-r726: Der Ordner trunk wurde als Administrator auf C: entpackt. Dann wurde das Skript DownloadUpdates.cmd von einem anderen, eingeschränkten Benutzer gestartet:

Code: Select all
C:\trunk-r726\cmd>DownloadUpdates.cmd w63 glb
Starting WSUS Offline Update download (v. 10.4b (r726)) for w63 glb...
Cleaning up existing directories...
C:\trunk-r726\iso\dummy.txt
Zugriff verweigert
C:\trunk-r726\log\dummy.txt
Zugriff verweigert
C:\trunk-r726\exclude\custom\dummy.txt
Zugriff verweigert
C:\trunk-r726\static\custom\dummy.txt
Zugriff verweigert
C:\trunk-r726\client\exclude\custom\dummy.txt
Zugriff verweigert
C:\trunk-r726\client\static\custom\dummy.txt
Zugriff verweigert
C:\trunk-r726\client\software\msi\dummy.txt
Zugriff verweigert
Updating static download definitions...


Die Testdatei ..\client\dummy.txt konnte anscheinend problemlos angelegt werden. Die vorhandenen Dummy-Dateien konnten aber trotzdem nicht gelöscht werden.
hbuhrmester
 
Posts: 525
Joined: 11.10.2013, 20:59

Re: Vermeiden von File integrity verification failures

Postby WSUSUpdateAdmin » 30.01.2016, 09:23

Moin!

Okay, ich hab's jetzt verstanden ;) und nochmal geändert.

Gruß
Torsten
WSUSUpdateAdmin
Administrator
 
Posts: 2245
Joined: 07.07.2009, 14:38


Return to Anregungen / Suggestions

Who is online

Users browsing this forum: No registered users and 37 guests

cron