Please reinclude the patch for codepage-based zip filenames

Bug #477755 reported by Alkis Georgopoulos
178
This bug affects 38 people
Affects Status Importance Assigned to Milestone
unzip (Debian)
Unknown
Unknown
unzip (Ubuntu)
Confirmed
Medium
Unassigned
Nominated for Lucid by Alexander Melnichuk
Nominated for Maverick by Alexander Melnichuk

Bug Description

Binary package hint: unzip

The unzip package didn't support codepage-based filenames, and a patch from altlinux was included in previous versions of unzip to make it support them with the command-line parameter "-O cpXXX". Some links about this problem are gathered in https://blueprints.launchpad.net/unzip/+spec/unzip-detect-filename-encoding
(e.g.: https://bugs.launchpad.net/debian/+source/unzip/+bug/10979/comments/15)

This parameter was removed in Karmic, and the changelog (https://launchpad.net/ubuntu/+source/unzip) states
"Enabled new Unicode support. Closes: #197427. This may or may not work
    for your already created zipfiles, but it's not a bug unless they were
    created using the Unicode feature present in zip 3.0."

I believe it *is* a bug, since it makes Linux users unable to open .zip files that *adhere* to the zip specification. It's like saying "utf8 is the way to go, so firefox won't support codepage-based websites anymore. Please convert all the websites of the internet to utf8 in order to see them". It's just not realistic... :-(

Please reinclude the patch.

For reproducing, here's a file that uses cp737: http://www.ypepth.gr/docs/metatheseis_090403.zip
I couldn't find *any* way to properly unzip it in Karmic, other than running Windows .zip utilities.

(btw, the bug #197427 that is referenced in the changelog is irrelevant, it's about ffmpeg being outdated)

Revision history for this message
Gábor Szécsi (deje07) wrote :

I totally agree that this is a huge issue with UnZip, all non-English speaking world suffers from this problem. Please DO include this patch as there is no tool exit for Karmic that could solve this filename encoding problem, while the problem is real and there is no acceptable workaround - other than having this feature in UnZip. It would also be a nice feature that some other tool like the gnome-file-roller had the ability to specify a different filename encoding. Because the software is free it should not be also lame, man! (excuse me for the tone but I'm a bit angry about this)

Revision history for this message
Dmitry Agafonov (dmitry-agafonov) wrote :
Rolf Leggewie (r0lf)
Changed in unzip (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Rolf Leggewie (r0lf) wrote :

Alexander and everybody else, please don't nominate for a release when we're still struggling to fix this in the development version. That's clutter and thus slows things down only further. If you want to see this problem fixed, DON'T do it. Please no comments like "what? I reported this x days/months/years/$whatever ago and you guys still haven't fixed it?" Please be assured that this problem is taken seriously. This is free (in a very broad sense) software, you can make sure this is fixed by providing code or paying someone to provide the code. Thank you for listening to my rant.

I want to make this the master bug for the problem that unzip currently has to deal with non-UTF, non-ASCII filenames. Subscribe to the bug, mark it as affecting you, provide patches. That'll help getting this on the radar and fixed. Please don't destroy the momentum by cluttering this bug with meaningless comments that will drive the devs away.

Unzip upstream uses a forum (!) to track bugs at http://www.info-zip.org/board/board.pl?c-izbugs/. I had a fairly long look around, but I'm not sure this has been reported upstream. Maybe somebody wants to report it there. It would increase the chances of getting a proper fix. Upstream devs aren't completely unaware of the issue, though, as reported in the Debian ticket.

FWIW, there is some Japanese discussion of this problem in bug 269482.

Revision history for this message
Fumihito YOSHIDA (hito) wrote :

> I'm not sure this has been reported upstream.
http://www.info-zip.org/board/board.pl?m-1248086794/ is upstream's answer.

we are still in the dilemma...

Revision history for this message
Rolf Leggewie (r0lf) wrote :

Alkis, you were looking at the Debian Changelog, so the bug number refers to the Debian BTS: http://bugs.debian.org/197427

Revision history for this message
Alkis Georgopoulos (alkisg) wrote :

Rolf, thank you, I realized that some hours after I filed the bug, but I didn't comment on it to minimize clutter.
Also thanks for your interest in fixing this.

Revision history for this message
Unxed (unxed) wrote :

Wrote a patch for unzip fixing this issue:
https://sourceforge.net/p/infozip/patches/29/

The same patch for p7zip:
https://sourceforge.net/p/p7zip/bugs/187/

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.