Ticket #3383 (closed defect: wontfix)

Opened 9 years ago

Last modified 5 years ago

slow open of zip files if unzip points to unzip-rcc (use unzip-plain as workaround)

Reported by: mcguard Owned by:
Priority: major Milestone:
Component: mc-vfs Version: master
Keywords: uzip, slow open, unzip-rcc Cc:
Blocked By: Blocking:
Branch state: no branch Votes for changeset:

Description

On my opensuse-13.1 system the contents of ZIP files appears
almost always after several seconds delay.

After inspecting strace log and playing with uzip I discovered the

reason: mc calls unzip-rcc which seems to cause a delay if piped from uzip

workaround: use unzip-plain instead, it works without delay

request: uzip works with unzip-rcc binary

Details:

I have unzip* and unzip-rcc* rpms installed.
unzip-rcc handles non-ascii chars in filenames (? or so).
There are two unzip-binaries in /usr/bin : unzip-plain and unzip-rcc.
The link /usr/bin/unzip -> /etc/alternatives/unzip -> /usr/bin/unzip-rcc

The line in /usr/lib/mc/extfs.d/uzip

my $app_unzip = "/usr/bin/unzip";

means uzip uses unzip-rcc which seems to cause a delay (not always, but often;
strace shows ~10 sec due to timeout after broken pipe error).
After changing unzip-rcc to unzip-plain the delay disappears.

For workaround you can either

change the line in /usr/lib/mc/extfs.d/uzip
my $app_unzip = "/usr/bin/unzip-plain";

or

redirect the link /etc/alternatives/unzip to /usr/bin/unzip-plain


To reproduce:

  1. check, if /usr/bin/unzip points to unzip-rcc
  2. get a zip file somewhere, I used

srock2.zip <-- wget srock2.zipwww.unige.ch/~vilmart/srock2.zip

  1. to see the effect it is enough to run uzip (I used one from mc version 4.8.11)

/usr/lib/mc/extfs.d/uzip list srock2.zip

the contents of the zip file is listed fast,
but the prompt comes often after noticeable delay.
The problem is in

sub mczipfs_list { ...if ($op_has_zipinfo) { while (<PIPE>) {...} <--blocker

uzip waits at closing } of the while loop after all output lines are printed.
There is no delay, if unzip-plain is used.
I cannot say more, sorry, perl is not my world...

Attachments

uzip_slow_with_unzip-rcc_001_timing.zip (9.6 KB) - added by mcguard 9 years ago.

Change History

comment:1 in reply to: ↑ description ; follow-up: ↓ 2 Changed 9 years ago by andrew_b

  • Status changed from new to closed
  • Resolution set to wontfix
  • Milestone Future Releases deleted

Replying to mcguard:

The line in /usr/lib/mc/extfs.d/uzip

my $app_unzip = "/usr/bin/unzip";

means uzip uses unzip-rcc

No. This means use /usr/bin/unzip and nothing else.

For workaround you can either

change the line in /usr/lib/mc/extfs.d/uzip
my $app_unzip = "/usr/bin/unzip-plain";

No. This is distro-specific stuff. We cannot use it by default for all mc users.

Ask mc maintainer in your distro to patch mc in the package.

Changed 9 years ago by mcguard

comment:2 in reply to: ↑ 1 Changed 9 years ago by mcguard

  • Status changed from closed to reopened
  • Resolution wontfix deleted
  • Summary changed from slow open of zip files if unzip points to unzip-rcc (use unzip-plain instead) to slow open of zip files if unzip points to unzip-rcc (use unzip-plain as workaround)

Replying to andrew_b:

Replying to mcguard:

The line in /usr/lib/mc/extfs.d/uzip

my $app_unzip = "/usr/bin/unzip";

means uzip uses unzip-rcc

No. This means use /usr/bin/unzip and nothing else.

Well, more precisely:

'.. means for my linux: uzip uses effectively unzip-rcc'.

Anyway, mc starts unzip, but effectively runs something different, which causes the delay problem.


For workaround you can either

change the line in /usr/lib/mc/extfs.d/uzip
my $app_unzip = "/usr/bin/unzip-plain";

No. This is distro-specific stuff. We cannot use it by default for all mc users.

Ask mc maintainer in your distro to patch mc in the package.

You are right. Oh, I see.. The ticket summary is confusing..
I do not want this to become default for all mc users.
It is only a workaround to avoid the problem.

I try to formulate my request more precisely:

Change uzip perl macro, so that it can use unzip-rcc binary without delay.
It is not about changing unzip name, it is about robust reading the unzip output like
tune pipe settings, timeout, error handling, or call unzip another way...
As before, uzip should call /usr/bin/unzip which can be plain unzip binary, or a link
pointing to unzip-rcc or unzip-plain binaries.

I suppose Perl has problems reading the output of unzip-rcc via pipe.
Any feedback?! Has anybody else observed this?
unzip binaries from unzip-rcc* and from unzip* (== plain, no rcc) packages make
different things during output. If unzip-rcc -l file.zip is called alone in xterm, a
small delay between the output and prompt return can be observed.
Plain unzip returns without noticeable delay. Any feedback..?
So, maybe it is enough to set longer timeout for the pipe in perl or so...
Please do not laugh if it is nonsence. I have zero Perl experience.
The problem place described in 'To reproduce' in 3383#comment:description was located by putting print
statements in the uzip macro (you can find modified uzip version as uzip_001_timing in attached
https://www.midnight-commander.org/attachment/ticket/3383/uzip_slow_with_unzip-rcc_001_timing.zip).

comment:3 Changed 9 years ago by andrew_b

  • Milestone set to Future Releases

comment:4 Changed 5 years ago by andrew_b

  • Status changed from reopened to closed
  • Resolution set to wontfix
  • Milestone Future Releases deleted
Note: See TracTickets for help on using tickets.