Zip extraction issues

Reported by @tonurics on Arch Linux bugtracker (FS#69253).

To clarify, assume you have zip file called "foo.zip" containing one item: "readme.txt"
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".

Seeing IBM437 makes me think of c104127...

Note: Arch Linux already switched to your p7zip fork and is providing 17.03 in the official repository.

[tonurics]

I've added some additional comments to the ticket on the Arch Linux bugtracker, along with a zip file you can use to reproduce the issues.

[tonurics]

I've updated the Arch Linux bugtracker with test results from releases and builds created from commits.

I skipped c3c8629 as it was marked as failing. Having said that jinfeihan57@c104127 is the first commit where the issue appears; which is also the one @jloqfjgk hinted at above.

[unxed]

Is this issue Arch-specific or it is reproduced on other distros using p7zip built from the same source tree?

PS: Attaching sample file from Arch issue:

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.
ComicInfo.zip

[unxed]

UPD: Built jinfeihan57/p7zip master on my Mint 20, issue is not reproducing on attached sample. Should I do it on Arch instead? What exact distro version should I use?

[unxed]

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

Tested that 17.03 binary on Mint 20, works fine on attached sample. Need to know exact Arch distro version to test on it.

[unxed]

Also, Arch Linux is rolling release so there is no version number.

Thanks! Will try to reproduce

[unxed]

If I pass env LANG=C then the bug can be reproduced.

Still not reproducting on my Mint even with this trick. Do you use sample attached above, ComicInfo.zip?

Btw, can anyone please help with QUICK way to install Arch in VirtualBox? Tried zen installer, it completed, but system stays unbootable. Maybe anyone can provide ready to run virtualbox image?

[unxed]

Try disabling UEFI in VirtualBox

Already disabled.

follow the official installation guide

It looks like it should take an hour or more. Can't afford it, alas. Isn't there a faster way?

[unxed]

Will try preinstalled version from here https://www.osboxes.org/arch-linux/

[unxed]

Will try preinstalled version from here https://www.osboxes.org/arch-linux/
Remember to do pacman -Syu so that all packages will be updated to the latest version.

Damn, it refuses to work also

[unxed]

Had to do the following:

1. from https://bbs.archlinux.org/viewtopic.php?pid=1653252#p1653252
   edit /etc/pacman.d/gnupg/gpg.conf and change the keyserver line to:
   keyserver hkp://keyserver.ubuntu.com

2. from https://wiki.archlinux.org/index.php/Pacman/Package_signing#Cannot_import_keys
   sudo pacman-key --init
   sudo pacman-key --populate
   sudo pacman-key --refresh-keys
   sudo pacman -Sy archlinux-keyring

sudo pacman -Syu

For full upgrade to complete. That Arch is a bit tricky thing :)

[unxed]

Trying to unzip attached sample looks a bit buggy (is askes to overwrite non-existent file), but extraction itself works ok no .so file is created.

[unxed]

Maybe I'm doing something wrong or need some additional steps to reproduce IBM437.so creation?
Exact image I used: https://nav.dl.sourceforge.net/project/osboxes/v/vb/4-Ar---c-x/2019.05/KDE/201905-kde-64bit.7z

[tonurics]

For completeness, here are my localization settings:
/etc/locale.gen
en_US.UTF-8 UTF-8
en_US ISO-8859-1
[If you change this: run locale-gen and restart.]

/etc/locale.conf
LANG=en_US.UTF-8
[If you change this: restart.]

@unxed You appear to only be using the x [eXtract files with full paths] command; which creates superfluous directories, where instead, it should be should be creating files.

The e [Extract files from archive (without using directory names)] command on the other hand does one of two things [depending on the zip archive]. It will either: try to replace the working directory [and fail] or create a file named "IBM437.so" with the contents of one the the file entries in the zip archive.

You can read my ticket on the Arch Linux bugtracker here: https://bugs.archlinux.org/task/69253?project=1&string=p7zip