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
Opened by tonurics (Tonurics) - Friday, 08 January 2021, 21:38 GMT
Last edited by Evangelos Foutras (foutrelis) - Tuesday, 19 January 2021, 14:12 GMT
|
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.
Tuesday, 19 January 2021, 14:12 GMT
Reason for closing: Fixed
Additional comments about closing: Breaking change temporarily reverted in p7zip 17.03-2.
And can confirm that the previous p7zip version handles these zip files correctly.
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.
Then report the issue upstream along with the test case.
[1] https://github.com/jinfeihan57/p7zip/
p7zip 17.01 = No Issue
p7zip 17.02 = No Issue
p7zip 17.03 = Broken
https://github.com/jinfeihan57/p7zip/commit/ba539b408cb93830463d9ecdf6537cf623c5270c = No Issue
https://github.com/jinfeihan57/p7zip/commit/36272c610cdcb1f2413344e8c4c9a34c5679e985 = No Issue
c3c8629b3b6d824c13d62efa5efda9e9139363a8 [Skipped, GitHub marked as failing.]
https://github.com/jinfeihan57/p7zip/commit/c104127e6a9364b8d6a1d79012e5249a129c3857 = Broken
https://github.com/jinfeihan57/p7zip/commit/e56ea97d89eb0cd59603402496a8208238b3fda2 = Broken