Unzip stopped working in 4.8.16

[lada.dvorak]

Content of zip file is empty after it is opened.

[andrew_b]

Unrepdoducable.
Works fine for me.

[lada.dvorak]

It is working in 4.8.15 but not in 4.8.16. I'm using ArchLinux? and official mc packages.

[andrew_b]

Replying to lada.dvorak:

It is working in 4.8.15 but not in 4.8.16. I'm using ArchLinux? and official mc packages.

Ask mc maintainer in ArchLinux?.

[zaytsev-work]

I've had a look at the PKGBUILD from Arch, and it seems to me that either the maintainer should add zip to depends or follow the BSD approach and call ./configure as follows:

ZIP=zip UNZIP=unzip ./configure

or whatever is appropriate for your system; otherwise it is assumed that zip is unavailable.

Can you try this and see if this helps?

[zaytsev-work]

P.S. Debian works around this with the following patch:

​http://anonscm.debian.org/cgit/collab-maint/mc.git/tree/debian/patches/uzip_528239.patch

[lada.dvorak]

Thanks for help, I've already reported it to ArchLinux? bug system.

[zaytsev-work]

Could you please leave a link here for reference?

[lada.dvorak]

Archlinux bug reference for this ticket:
​https://bugs.archlinux.org/task/48619

[mooffie]

I too have this problem. Since I compile MC from source the I don't get the Debian/Ubuntu patch.

I tracked down the problem: for the $op_has_zipinfo == 0 case, ​our regex expects unzip's date to be in '(mm)-(dd)-(yy|yyyy)' format wheres mine emits them in '(yyyy)-(mm)-(dd)' format. It turns out it's an unzip compile-time setting:

​http://fossies.org/dox/unzip60/list_8c_source.html#l00309

(Its INSTALL file explains that you can do -DDATE_FORMAT=DATE_FORMAT=DF_DMY or DF_MDY or DF_YMD when compiling.)

Do you want me to write a patch accommodating the YMD case? Or do you consider the $op_has_zipinfo == 0 case obsolete?

[mooffie]

Or, here's a patch.

It turns out that Debian (and derived distros) ​switched to compiling unzip with YMD date order in 2009.

(BTW, I don't think we need to worry about supporting DMY ordering (as opposed to MDY) because if some distros bothered to change the default (MDY) then it's likely they'd picked the better YMD method instead (as it's the unambiguous ISO format).)

---

Also, it turns out that the reason our 'configure' doesn't detect that zipinfo is installed on my system is because it does the detection (in mc-vfs-extfs.m4) by running "unzip -Z", which on my system exits with an error ("error: zipfile probably corrupt (segmentation violation)"). Running /usr/bin/zipinfo too exits with error. It seems like a bug in unzip. I'm using the latest Ubuntu, 15.10, but I also checked this with Ubuntu 15.04 and the bug exists there as well.

@lada.dvorak: Could you run "unzip -Z" and tell us if it prints some error on the last line? (you can also do "echo $?" to see the exit code.)

[lada.dvorak]

I've tested it and it does not print any error. echo $? is 0.

[mooffie]

Replying to lada.dvorak:

I've tested it and it does not print any error. echo $? is 0.

Ok.

(This "error: zipfile probably corrupt" bug isn't really relevant for your case because you're using your distro's package, instead of running 'configure' yourself. I just wanted to see how prevalent was this bug.)

[zaytsev]

Hmmm, I've just found #423, which apparently is about the problem @mooffie is talking about (as opposed to Arch not having zip in depends in the first place). If it's really the same, I should close it as duplicated of this one then. (Funnily, it was already closed as a duplicate by Slava once ~ 7 years ago, but a duplicate of which ticket?! Who knows...)

[mooffie]

Replying to zaytsev:

Hmmm, I've just found #423, which apparently is about the problem @mooffie is talking about

Right :-]

If it's really the same,

Yes. I examined its patch carefully and it does the same thing. But IMO my patch is better (the description too).

I should close it as duplicated of this one then.

This seems sensible.

[mooffie]

(I updated the patch to make two comment lines better (just added punctuation marks: "(HH)(MM)" -> "(HH):(MM)" etc.). I didn't modify the code itself.)

[zaytsev]

Ticket #423 has been marked as a duplicate of this ticket.

[zaytsev]

Branch: 3622_fix_unzip_extfs
Initial changeset: a1d2c81d15b414e17102cc5abfc94c60b1ba306e

[zaytsev]

FYI, I have tried zipinfo -Z on the latest Debian 8 amd64 and Fedora 23 amd64, and in both cases it runs through and the exit code is 0; this probably means that Debian maintainers can drop their zipinfo patch when this branch is merged and if uzip is added as a build requirement...