#2099 7z hangs if a file is deleted while creating a zip archive

[Cedric Krumbein]

If a file is deleted from a directory tree while 7z is creating an archive in zip format:
7z -tzip a my-archive /my-directory-tree
7z will hang:
WARNING: No such file or directory
/my-directory-tree/my-missing-file
(Makes no further progress)

This doesn't happen if using default 7z format:
7z a my-archive /my-directory-tree

WARNING: No such file or directory
/my-directory-tree/my-missing-file
(Proceeds to completion.)

[Igor Pavlov]

I can't reproduce the problem.
Please check it again.
And try latest version 17.01
try also -mmt1 switch

[Cedric Krumbein]

Wow, the -mmt1 switch solves the problem! 7-Zip no longer hangs!
Unfortunately, we can't use it because the Java zip library doesn't like .zip files made with the -mmt1 switch.

Is there a 17.01 build for Fedora/RHEL/CentOS?

[Igor Pavlov]

The call with -mmt1 and the call without -mmt1 must produce same archives.
I still want to fix the problem for case without -mmt1.
So what version of p7zip it was?

[Cedric Krumbein]

16.02

[Cedric Krumbein]

This was run on a CentOS-7 VM.
I installed 7z by running the command 'sudo yum install p7zip p7zip-plugins'.

[Cedric Krumbein]

How to repro:

On a Linux host, find or create a large directory tree. It must be large enough that it will take at least a minute to compress. Select a file deep in the tree that can be moved:

my-tree/.../my-file

Open two shells on the host.

In the first shell, start a compression:

7z -tzip a my-tree-backup my-tree

In the second shell, immediately after starting the compression, move the selected file out of the tree:

mv my-tree/.../my-file .

When 7z reaches the selected file and finds it missing, it will output a warning:

WARNING: No such file or directory
my-tree/.../my-file

7z will then be suspended, never making further progress.

Note that this occurs only if using .zip format. 7z will complete successfully if using .7z format.

[Igor Pavlov]

1) please check the problem with simplest multithreading case with -mmt2 switch.
2) can you check same -mmt2 with 7z.exe or 7za.exe for Windows version of 7-Zip via wine - with both versions: 16.04 and 17.01 beta?

[Igor Pavlov]

I suppose it's bug of p7zip port of windows code for CRITICAL_SECTION object.
More details are here:
https://sourceforge.net/p/p7zip/bugs/203/

Now there some ways to fix the problem:
1) you can fix p7zip code in Threads.c
2) I'll change ZipUpdate.cpp also to eliminate bad case. So next version of 7-zip code will be able to work with old "bad" Threads.c of p7zip.

In any case you must recompile p7zip.
But I don't know when new version of p7zip will be released.

-mmt1 must work OK.

Thanks for report!

[jpfle]

Are there news about this bug? I confirm it on Xubuntu 19.10 with this 7z version:

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=C,Utf16=off,HugeFiles=on,64 bits,4 CPUs Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz (306A9),ASM,AES-NI)

I also confirm that using -mmt1 is a successful workaround.