FS#69253 - [p7zip] Zip extraction issues.

Attached to Project: Arch Linux
Opened by tonurics (Tonurics) - Friday, 08 January 2021, 21:38 GMT
Last edited by Evangelos Foutras (foutrelis) - Tuesday, 19 January 2021, 14:12 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Evangelos Foutras (foutrelis)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

[Description:]

Having issues related to extracting certain zip files from the internet. I can't say for certain the exact cause and have not been able to create problem zip files locally on Linux. But using zipdetails, to compare locally created zip files [with the same data, that extract correctly] vs remote ones those that don't: the problem zip files appear to have various extra File Attributes [such as "NTFS FileTimes"].

[Additional info:]
* package version(s): 17.03-1

[Steps to reproduce:]

When using 7z or 7za with the x switch [to extract to a directory], 7z appears to create a directory entry for what should be a file, then throw an error asking to replace said directory with a file. To clarify, assume you have zip file called "foo.zip" containing one item: "readme.txt" and ask 7z to extract to the directory /tmp/1 [i.e. `7z x -o/tmp/1 foo.zip`], 7z will create a new directory called "/tmp/1/readme.txt" then throw an error asking to replace it, answering yes will result in the directory being replaced with the readme.txt file.

Taking the same file above and instead using switch e [to extract to the working directory, i.e `7z e foo.zip`], one of two things will happen [depending on the zip file]: sometimes 7z creates a file named "IBM437.so" with the contents of "readme.txt". Or 7z throws an error asking to "replace the existing file" "./.", then throws an error "ERROR: Can not create file with auto name : ./" when answering yes to "Auto rename all".

unzip or Ark appear to have no issues extracting these files. I believe this issue first appeared in the latest p7zip release.
This task depends upon

Closed by  Evangelos Foutras (foutrelis)
Tuesday, 19 January 2021, 14:12 GMT
Reason for closing:  Fixed
Additional comments about closing:  Breaking change temporarily reverted in p7zip 17.03-2.
Comment by tonurics (Tonurics) - Friday, 08 January 2021, 21:44 GMT
For completeness, answering yes to replace "./." during e extract, results in "ERROR: Can not delete output folder : Invalid argument : ./"
Comment by tonurics (Tonurics) - Saturday, 09 January 2021, 16:02 GMT
I have rebuilt and installed 16.02-6 from here: https://github.com/archlinux/svntogit-packages/tree/a82b67f5d36f374afd154e7648bb13ec38a3c497

And can confirm that the previous p7zip version handles these zip files correctly.
Comment by tonurics (Tonurics) - Saturday, 09 January 2021, 16:22 GMT
I found a small zip file that can be used to reproduce the issue in 17.03-1.

Both the x and e switch options will result in the issues I described above. In the case of the e switch: the "IBM437.so" file will appear, and not the error trying to replace the working directory.
Comment by loqs (loqs) - Saturday, 09 January 2021, 19:27 GMT
Can you try 17.0.1 of the fork Arch switched to [1] to see if that is affected? If not 17.0.2 then of the fork. Then bisect between the good and bad version to determine which commit introduced the issue.
Then report the issue upstream along with the test case.

[1] https://github.com/jinfeihan57/p7zip/
Comment by tonurics (Tonurics) - Sunday, 10 January 2021, 02:18 GMT
I tested the zip file attached above with the three 7z release binaries posted at: https://github.com/jinfeihan57/p7zip/releases

p7zip 17.01 = No Issue
p7zip 17.02 = No Issue
p7zip 17.03 = Broken
Comment by tonurics (Tonurics) - Sunday, 10 January 2021, 02:44 GMT Comment by txtsd (txtsd) - Sunday, 10 January 2021, 18:51 GMT
I can confirm this is happening with 17.03

Loading...