Zip extraction issues #112
Comments
|
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. |
|
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. |
|
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:
|
|
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? |
Tested that 17.03 binary on Mint 20, works fine on attached sample. Need to know exact Arch distro version to test on it. |
Thanks! Will try to reproduce |
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? |
Already disabled.
It looks like it should take an hour or more. Can't afford it, alas. Isn't there a faster way? |
|
Will try preinstalled version from here https://www.osboxes.org/arch-linux/ |
Damn, it refuses to work also
|
|
Had to do the following:
sudo pacman -Syu For full upgrade to complete. That Arch is a bit tricky thing :) |
|
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. |
|
Maybe I'm doing something wrong or need some additional steps to reproduce IBM437.so creation? |
|
For completeness, here are my localization settings: /etc/locale.conf @unxed You appear to only be using the The You can read my ticket on the Arch Linux bugtracker here: https://bugs.archlinux.org/task/69253?project=1&string=p7zip |
|
As for your Arch installation, I'm not sure you have a fully working system. If you continue to run into problems reproducing the issue: As Arch is a rolling release, if you have an image that hasn't been updated for some time: it can get stuck where new packages can't be updated and the best option is to install a fresh copy [which is generally pretty quick, if you follow along with the Installation guide; you might even have just been able to use the install media as a sort of CLI only live CD]. Having said all that, things for taking time to get Arch running for testing! |
|
I can confirm this is happening on Arch with 17.03 Arch doesn't do anything strange to build it though: |
|
At the end of the new code added in c104127, So the The following approach correctly extracts diff --git a/CPP/7zip/Archive/Zip/ZipItem.cpp b/CPP/7zip/Archive/Zip/ZipItem.cpp
index 353e895..4d48296 100644
--- a/CPP/7zip/Archive/Zip/ZipItem.cpp
+++ b/CPP/7zip/Archive/Zip/ZipItem.cpp
@@ -423,10 +423,10 @@ void CItem::GetUnicodeString(UString &res, const AString &s, bool isComment, boo
const char* src = s.Ptr();
size_t slen = s.Len();
size_t dlen = slen * 4;
- const char* dest = s_utf8.GetBuf_SetEnd(dlen + 1); // (source length * 4) + null termination
+ const char* dest = s_utf8.GetBuf_SetEnd(dlen); // (source length * 4)
size_t done = iconv(cd, (char**)&src, &slen, (char**)&dest, &dlen);
- bzero((size_t*)dest + done, 1);
+ s_utf8.ReleaseBuf_SetEnd(s_utf8.Len() - dlen);
iconv_close(cd);
|
|
I don't work on arch linux. |
|
For me 17.03 testing outputs
|
|
@biopsin I assume you are seeing still seeing the erroneous folder creation problem with the I would be cautious of using the |
|
Yes I see it; extracting with 7z x $1 |
I wouldn't consider this to be an Arch Linux issue. More likely this is related to newer libstdc++ or some other core library. For what it's worth, this is also reproducible on Fedora 32 and Fedora 33 ( @unxed: Could you test on Fedora 33 (or Fedora 32) which works as a live disc and doesn't require installation/configuration? |
|
I just tested the following distros livecds in VirtualBox [except Arch] using default settings and the compiled p7zip 17.03 release:
Note: Seeing that Sparky Linux passed [which is Debian Testing], I would assume: that all other Debian distros based would likely pass. So stuck to testing independent upstream source distros with recent releases. |
|
It doesn't really matter why Debian doesn't repro this exact bug. Increasing the length/size of And on second run: Either a |
@jloqfjgk [All your comments appear to have been deleted.] For edification: I was actually curious about that myself and did try to test it. But the 17.03 release binary didn't run. And not knowing enough about Alpine/musl: didn't want to try compiling it myself and create any red herrings or false feedback. |
ghost
mentioned this issue
|
What is the status of this issue? |
|
On Ubuntu 20.04 I have this issue with Zip extraction. |
I've tried to revert commit c104127 and that issue has gone. |
|
Hi, I don't know if it is related with the same issue: I've tested that some ZIP archives are not extracted correctly with p7zip 17.04, but they are correctly extracted using the vanilla p7zip 16.02, I've tested the issue on Ubuntu 18.04 and 20.04 x86_64. Some example of the archives showing the issue are: Extraction ends successfully but part of the content is not extracted using p7zip 17.04 - e.g. some files are extracted as empty folders, some files are not extracted at all - and I can't find anything about the error(s) in the log of the operation. Extracting same archives with the vanilla p7zip 16.02, or with other archive managers, produces the correct number of files and folders as output. Listing and testing the archives with p7zip 17.04 is successful and no issues (e.g. data errors) are reported for the archives. |
|
@peazip just tested extracting 7.2.1.zip and and the other one 357M - does this sound correct to you? |
Correct, the archives extracted with p7zip 16.02 are 464KB and 357MB respectively, same result extracting them with other archive managers. |
|
foutrelis already found the source of the bug. What then happens is that the function that splits file paths gets confused and thinks the file path does not end at the file name. For instance, it thinks that something like is Because of that, depending on the position of the moon, if it is raining and if you are wearing matching socks, when that path is split, sometimes the rest of the code will think that "file.txt" is not the last part of the path, but yet another directory. And then it will create a directory named "file.txt" and continue with the file extraction. And it will see that it is supposed to extract a file named "file.txt" inside that last directory it has just created. A directory that happens to be named... "file.txt" And that is why I and the people posting here in this issue keep seeing 7z saying that there is already a file named "xxx" inside the directory you are extracting the archive and keeps asking if you want to overwrite it or not. A quick fix is to simply set the length of p7zip/CPP/7zip/Archive/Zip/ZipItem.cpp Line 433 in a45b883 The code inside that function also seems to be doing something weird with the return of the This bug is still active in the latest release (v17.05) and, although I didn't check, I wouldn't be surprised if something similar happens in other parts of the code. That being said, it seems the newer commits changed While we wait, here is a patch that should fix the issue --- old/CPP/7zip/Archive/Zip/ZipItem.cpp 2023-03-03 12:16:28.000000000 +0000
+++ new/CPP/7zip/Archive/Zip/ZipItem.cpp 2023-04-15 18:03:22.996666664 +0000
@@ -424,13 +424,16 @@
size_t slen = s.Len();
size_t dlen = slen * 4;
const char* dest = s_utf8.GetBuf_SetEnd(dlen + 1); // (source length * 4) + null termination
+ const char* destStart = dest;
size_t done = iconv(cd, (char**)&src, &slen, (char**)&dest, &dlen);
bzero((size_t*)dest + done, 1);
iconv_close(cd);
- if (ConvertUTF8ToUnicode(s_utf8, res) || ignore_Utf8_Errors)
+ AString s_utf8_correctLength;
+ s_utf8_correctLength.SetFrom(s_utf8, dest - destStart);
+ if (ConvertUTF8ToUnicode(s_utf8_correctLength, res) || ignore_Utf8_Errors)
return;
}
}
|
latest.sh can now retrieve the latest commit on Master in github repositories download.sh correctly deals with .zip files now. Also switch from p7zip to unzip when dealing with .zip because the current version of p7zip (17.05) has a very dangerous bug in the zip file handler p7zip-project/p7zip#112
|
Managed to reproduce bug on my Mint 21.3. Followed this instruction: Bug do not reproduces in far2l terminal, but reproduces in GNOME Terminal. As for ComicInfo.zip, bug reproduces or not depending on current folder name, and only if binary was built on Alpine Linux (it was built by @spvkgn in alpine:latest container, probably it's the current stable alpine version). For example, it reproduces if archive and archiver are inside After applying some fixes to #232 it stopped reproducing for me. Thanks @libTorrentUser ! |
Reported by @tonurics on Arch Linux bugtracker (FS#69253).
Seeing
IBM437makes me think of c104127...Note: Arch Linux already switched to your p7zip fork and is providing 17.03 in the official repository.
The text was updated successfully, but these errors were encountered: