Im Wesentlichen habe ich festgestellt, dassp7zipdurchsucht zuerst das zu komprimierende Verzeichnis und komprimiert diese Dateien dann in einem einzigen ZIP-Format.
Stellen Sie sich das folgende Szenario vor: Ich habe Hunderte von GB an Dateien und Ordnern, die zuerst gescannt und komprimiert werden. Nehmen wir an, ich habe eine Datei gelöscht, nachdem der Scanvorgang abgeschlossen ist. Ich weiß nicht, wie eine Datei nach Abschluss des Scanvorgangs fehlen kann, aber dieses Verhalten wurde in der Produktion beobachtet, also habe ich sie auf meinem lokalen Computer selbst gelöscht. In diesem Fall wird der folgende Fehler ausgegeben und es bleibt auf unbestimmte Zeit hängen.
7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,6 CPUs Intel(R) Core(TM) i5-9500T CPU @ 2.20GHz (906EA),ASM,AES-NI)
Scanning the drive:
29741 folders, 48865 files, 5035919485 bytes (4803 MiB)
Creating archive: /home/mymachine/Downloads.zip
Items to compress: 78606
WARNING: No such file or directory
/var/webarch/data/fs-root/538/2022/05/20/19964
Gibt es also ein Flag in p7zip oder einen Hack, mit dem diese Warnungen ignoriert und mit dem Komprimieren fortgefahren werden kann? Wir können beispielsweise einige der nach dem Scannen fehlenden Dateien ignorieren, anstatt in der Produktion einen Timeout-Fehler auszulösen.
Antwort1
Dies wurde im Fehlerbericht erwähnt #2099 7z bleibt hängen, wenn beim Erstellen eines Zip-Archivs eine Datei gelöscht wird ab 2017.
Der Entwickler versprach, das Problem zu beheben, tat dies jedoch nicht.
Er hat einen Workaround vorgeschlagen, der darin besteht, den Schalter hinzuzufügen -mmt1
, der die Anzahl der Threads auf eins (1) setzt. Anscheinend wird das Hängenbleiben durch einen Multithread-Konflikt verursacht, wenn eine Datei von einem der Threads nicht gefunden wird, und wird durch die Verwendung von nur einem Thread vermieden.