Ticket #3622 (closed defect: fixed)

Opened 3 years ago

Last modified 3 years ago

Unzip stopped working in 4.8.16

Reported by: lada.dvorak Owned by: zaytsev
Priority: major Milestone: 4.8.17
Component: mc-vfs Version: 4.8.16
Keywords: zip Cc:
Blocked By: Blocking:
Branch state: merged Votes for changeset: committed-master

Description

Content of zip file is empty after it is opened.

Attachments

3622-Ticket-3622-extfs-uzip-fix-date-parsing.patch (2.5 KB) - added by mooffie 3 years ago.

Change History

comment:1 Changed 3 years ago by andrew_b

  • Version changed from master to 4.8.16

Unrepdoducable.
Works fine for me.

comment:2 follow-up: ↓ 3 Changed 3 years ago by lada.dvorak

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

comment:3 in reply to: ↑ 2 Changed 3 years ago by 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?.

comment:4 Changed 3 years ago by 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?

comment:5 Changed 3 years ago by zaytsev-work

comment:6 Changed 3 years ago by lada.dvorak

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

comment:7 Changed 3 years ago by zaytsev-work

Could you please leave a link here for reference?

comment:8 Changed 3 years ago by lada.dvorak

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

comment:9 Changed 3 years ago by 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?

comment:10 Changed 3 years ago by 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.)

comment:11 follow-up: ↓ 12 Changed 3 years ago by lada.dvorak

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

comment:12 in reply to: ↑ 11 Changed 3 years ago by 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.)

comment:13 follow-up: ↓ 14 Changed 3 years ago by 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...)

comment:14 in reply to: ↑ 13 Changed 3 years ago by 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.

Changed 3 years ago by mooffie

comment:15 Changed 3 years ago by 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.)

comment:16 Changed 3 years ago by zaytsev

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

comment:17 Changed 3 years ago by zaytsev

  • Milestone changed from Future Releases to 4.8.17

comment:18 Changed 3 years ago by zaytsev

  • Owner set to zaytsev
  • Status changed from new to accepted

comment:19 Changed 3 years ago by zaytsev

  • Branch state changed from no branch to on review

Branch: 3622_fix_unzip_extfs
Initial changeset: a1d2c81d15b414e17102cc5abfc94c60b1ba306e

comment:20 Changed 3 years ago by 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...

comment:21 Changed 3 years ago by andrew_b

  • Votes for changeset set to andrew_b
  • Branch state changed from on review to approved

comment:22 Changed 3 years ago by zaytsev

  • Status changed from accepted to testing
  • Votes for changeset changed from andrew_b to committed-master
  • Resolution set to fixed
  • Branch state changed from approved to merged

comment:23 Changed 3 years ago by zaytsev

  • Status changed from testing to closed
Note: See TracTickets for help on using tickets.