unzip fails to deal correctly with filename encodings

Bug #580961 reported by Rolf Leggewie on 2010-05-15
This bug affects 1458 people
Affects Status Importance Assigned to Milestone
Ubuntu Japanese Kaizen Project
High
Unassigned
unzip (Ubuntu)
Critical
Unassigned
Precise
High
Unassigned
Quantal
High
Unassigned
Raring
High
Unassigned
unzip (openSUSE)
Fix Released
Medium

Bug Description

Binary package hint: unzip

This is a fairly annoying bug that's been around and known at least since 2005. It's very visible as it will very often make exchange of zip files with Windows users impossible, for example. As such, it gathered it's fair share of "me too" and "how dare you haven't fixed this yet!!111!" comments.

Problem description:
zip/unzip and the specification fall short when dealing with non-ASCII filenames not encoded in UTF-8

test case:
do an "unzip -l" on the file http://tinyurl.com/2aofpxs and witness the question marks

affected programs:
the problem is in unzip itself, but affects GUI like xarchiver, file-roller, etc. that rely on unzip for the decompression

suggested solutions (most are workarounds, not proper fixes):
 a) reintroduce patch for codepage-based zip filenames: bug 477755, http://tinyurl.com/2aqdbqg (Ubuntu blueprint)
 b) unzip filename according to locale: bug 203609
 c) Ubuntu JP has a patch, probably not generally applicable, bug 269482
 d) Russian altlinux distro uses natspec lib and patched zip binary

natspec was mentioned in bug 477755 comment #2 and may indeed be a proper fix, needs closer inspection (I haven't really looked, yet. As discussed in https://bugzilla.gnome.org/show_bug.cgi?id=306403 there is no failsafe, straight-forward way to fix this in all cases. Nonetheless, the current situation can and should be improved. There's some good ideas floating around. It needs somebody to pull and wrap them together.

It's unfortunate the FOSS community so far hasn't been able to fix this rather visible problem. I'm opening this ticket as a master bug and clean slate to document the issue and current status. Please don't ruin it by making above-mentioned unhelpful comments, they actually slow things down! Please don't nominate for a release.

Unless you're a dev and can provide a patch, you should think VERY carefully to do anything but

1) subscribe yourself to this ticket
2) mark this bug as affecting you
3) tell me via mail about other bugs you think are a duplicate of this one, discussing the same problem

1) to 3) will showcase to the devs how many people are affected and that is the only real chance we have for somebody to take a serious look. "Me too" comments do the opposite, so again, please don't do it.

Created attachment 319015
An archive file with cyrillic file names included

User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.0.13) Gecko/2009080200 SUSE/3.0.13-0.1.2 Firefox/3.0.13

There are several discussions about the problem concerning cyrillic filenames in zip archives and unzip package. Unzip out-of-the-box (compiled from sources) does not choose filenames encoding correctly.

Developers from Ark say me, that the error is completely from info-zip project (https://bugs.kde.org/show_bug.cgi?id=204984).

There are sime patches to info-zip's unzip package, that makes unzip extract filenames with correct encoding. But maintainers of info-zip project rejected these patches (http://www.info-zip.org/board/board.pl?m-1248086794).

It would be nice to include this package in main openSuSE distribution.

Reproducible: Always

Steps to Reproduce:
1. Create zip-archive, containing files with cyrillic names under Windows.
2. Try to open it with unzip under SuSE
Actual Results:
Filename encoding is incorrect. Example:

pavel@pavel:~/tmp> unzip ReportPacket_DBV90821CJ.zip
Archive: ReportPacket_DBV90821CJ.zip
  inflating: ???????? ????? (????????).pdf
  inflating: ???????? ????? (??????????).pdf

Expected Results:
Results, produced with natspec patch from sisyphus

pavel@rzn-sepak-bpa:~/backup> pavel@rzn-sepak-bpa:~/temp> unzip ReportPacket_DBV90821CJ.zip
Archive: ReportPacket_DBV90821CJ.zip
  inflating: ????????? ????? (??????????).pdf
  inflating: ????????? ????? (??????????).pdf

We have found solution. But it requires additional libraries to convert file names on the fly.

The library is librcc especially created for handling non utf encoded file names.

How we can proceed then? RPM packages are built on OBS and tested. Should we create submit request?

The librcc and patched unzip are here:
http://download.opensuse.org/repositories/home:/Lazy_Kent/openSUSE_11.2/

*** Bug 575715 has been marked as a duplicate of this bug. ***

This is also a problem with the letters 'æ ø å' used in some of the Scandinavian alphabets.

It's also an issue for tar's created by 7zip on Windows.

Unzip 6.0 and the packages from home:/Lazy_Kent/openSUSE_11.2/ mentioned in comment 1 doesn't change anything on my system. (11.2 x86_64)

I made a submit request to Factory:
https://build.opensuse.org/request/diff/39326

Confirmed, it works at least with Russian, Czech and Slovak.
http://lizards.opensuse.org/2010/04/07/call-for-testing-unzip-feature/

% LANG=cs_CZ.utf8 unzip -l test-cz.zip
Archive: test-cz.zip
  Length Date Time Name
 -------- ---- ---- ----
      117 03-18-10 15:24 aábcčdďeéěfghchiíjklmnňoópqrřsštťuúůvwxyýzžAÁBCČDĎEÉĚFGHCHIÍJKLMNŇOÓPQRŘSŠTŤUÚŮVWXYÝZŽ.txt
 -------- -------
      117 1 file

I won't accept the patch for openSUSE because upstream doesn't accept it and openSUSE would have to maintain this patch indefinitely. If this or a similiar patch gets accepted upstream I'll help in backporting it.

What about changing the file to Sisyphus' patched version? If openSUSe cannot maintain it, let's Alt Linux team do the maintenance and regard them as upstream of a forked version?

Well it is really annoying: nobody can open archives made under Windows. People of business say Linux is buggy: it even cannot open archives properly. The same say government officials.

@Philipp
Chances to push this patch to upstream is very small or even not possible at all. Other distributions tried to accomplish that without success.

The upstream statement is: The trend in IT is to use UTF8.
That's why patch is not accepted.

Then why we can't accept this patch as openSUSE specific to close such annoying bug? And maintain it until good time comes. openSUSE maintain a numbers of specific patches for rpm, OpenOffice.org

If you won't maintain patch, please let community to do it.
The patch is small. It introduces new header and changes few strings of main code.

We tested patched unzip for two-three months and it just works. Also we got positive feedback on Czech and Slovak in addition to Russian language.
It also pretty applicable on latest 6.0 unzip version.

OK, after thinking about this I have added the patch to our unzip and will keep it at least as long as the package builds and the patch doesn't need extra work. Kyrilk, would you be willing to act as co-maintainer? Or to ask more more broadly, would anyone of you be willing to comaintain zip/unzip?
I'll also try to get an update for 11.2 out of the door.

Philipp, I made sr#39767.

At the moment we have librcc0 in Factory only. So we may build patched unzip against Factory.
I added %if 0%{?suse_version} > 1120 for all the chahges.

> would you be willing to act as co-maintainer?

Yes, I'd like to take this role.

Rolf Leggewie (r0lf) on 2010-05-15
Changed in unzip (Ubuntu):
importance: Undecided → High
status: New → Triaged
description: updated
Rolf Leggewie (r0lf) on 2010-05-15
description: updated
description: updated
Rolf Leggewie (r0lf) on 2010-05-15
description: updated
Rolf Leggewie (r0lf) on 2010-05-15
description: updated
Changed in unzip (Debian):
status: Unknown → Confirmed
171 comments hidden view all 198 comments
Rolf Leggewie (r0lf) wrote :

Martin, do I read the Changelog correctly that you assumed the Ubuntu delta for unzip 5.52-12ubuntu1 only concerned UTF-8 and thus you dropped it when Debian released 6.0-1? In fact, I believe this then introduced a regression that made bug 10979 (or this bug, whichever you prefer ;-)) to return. Actually, unicode is mostly not an issue and dealt with in 6.x. What's remaining problematic is non-UTF-8, non-ASCII filenames in zip files. It's my understanding that's what this has been about all along. I believe we will need to reintroduce a similar patch or look into natspec which seems to be able to deal more elegantly and automatically with the matter.

Changed in ubuntu-jp-improvement:
status: New → In Progress
status: In Progress → Fix Committed
assignee: nobody → Rolf Leggewie (r0lf)
Martin Pitt (pitti) wrote :

Hm, the original patch from https://edge.launchpad.net/ubuntu/+source/unzip/5.52-9ubuntu3 talked about "UTF-8 file names" all along. Unfortunately I cannot read the upstream bug, it's in Russian.

So if this was about non-UTF-8, it was very misleading. Sorry for dropping it prematurely then.

Rolf Leggewie (r0lf) wrote :

Martin, thank you for your comment. The question is now how to deal with this regression. One way is of course to reintroduce the patch from bug 477755 (not sure if it still applies cleanly). The other option that seems to be a more general solution is the one offered by natspec. I'm currently in the process of working with Andrew Shadoura to try and get the libnatspec package into Debian.

I would think the following is the best course of action.

1) reintroduce (an adapted) patch from bug 477755 for lucid. don't close this ticket.
2) evaluate libnatspec for maverick

What do you think? Can you take care of part 1)?

Rolf Leggewie (r0lf) wrote :

failed to mention the reasoning behind my proposal.

unzip is in main. If unzip were to depend on libnatspec it would need to be in main, too. This can not happen before Maverick. But I think we should try to get a fix for Lucid as well, especially since this is a regression from an earlier version and the solution should be reasonably easy to implement.

Rolf Leggewie [2010-05-20 10:59 -0000]:
> 1) reintroduce (an adapted) patch from bug 477755 for lucid. don't close this ticket.
> 2) evaluate libnatspec for maverick
>
> What do you think? Can you take care of part 1)?

Sorry, I don't think I can. I'm on rotation for this cycle, and not
working in the platform team. But I'm happy to sponsor a fixed package
(maverick/lucid-proposed).

Thanks,

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Rolf Leggewie (r0lf) wrote :

OK, understood.

But I think that's a bit lame. I'm not throwing around blame, but it seems your upload introduced the regression as part of your paid work and now you want others to fix it. I have no beef in this, am not being paid for it, yet I have already volunteered and done all the recent bug work, started to work on evaluating natspec for maverick, etc. Simply because I want the Japanese folks to drop one part of their delta to Ubuntu.

Frankly, I believe you should play your part, being currently on the platform team or not. Especially since it's probably nothing more than taking the old patch, maybe tweaking it slightly, testing and uploading.

167 comments hidden view all 198 comments

do we really want to take 2 new libraries for 11.2? not sure.

In reply to C12
More & more customers are having incoming zip from differents encodings and it's really a pain to explain, oh this zip should be unzip under window to get the right encoding. We look like charlot.

So as 11.2 as a long life in front of it, yes I'm voting for having it include as fast as possible. The bug start under 11.2, so I feel it's better to close it on 11.2, and be sure it was integrated in 11.3

Or (I'm only seeing ma world part :-) ) there's a much complicated implication, if so it should be explain.

167 comments hidden view all 198 comments

Problem with curillic in archives

Nelson Benitez (gnel) wrote :

Hi Rolf, I think your first comment "Actually, unicode is mostly not an issue and dealt with in 6.x. " is not true.. if I zip utf8 filenames with non-ascii chars (with zip command or file-roller) then I can't unzip them with file-roller.. because 'unzip -l' lists them wrong.

See my comment on upstream bug https://bugzilla.gnome.org/show_bug.cgi?id=619116#c4

So I think this bug still applies for UTF-8 files (those with non-ascii chars).. the problem here is Info-zip doesn't even have a bug-tracker, but the file-roller problem could be solved just installing 7-zip package (again see my upstream comment..).

let me know if I'm wrong in my observations..

Matteo Rapone (nedanfor) wrote :

I agree with you, Nelson. Are you sure that 7-zip package solves the problem?

166 comments hidden view all 198 comments

I'm not happy about adding two new libraries to a released product, but in this case I think it should be fine if someone will maintain them. (+1)

so lets do it. :)

The SWAMPID for this issue is 33540.
This issue was rated as low.
Please submit fixed packages as soon as possible.
Also create a patchinfo file using this link:
https://swamp.suse.de/webswamp/wf/33540

Update process started ... be so kind and submit fixed sources and a patchinfo.

168 comments hidden view all 198 comments

@Matteo

I can confirm that the p7zip package does not completely solve the problem in the following usage scenario:

Several files, each with a korean filename(presumably with euc-kr or cp949 encoding) compressed in a windows environment to .zip.
Fileroller shows invalid filenames when opening the archive.

without the 7-zip package(p7zip-full): the filenames appear as invalid, including various illegal characters, which makes it impossible even to extract the files

with the 7-zip package: the filenames appear as invalid(but different from above), but is extractable. Although I cannot say with certainty, the invalid filenames appear as something one would expect when reading a korean webpage whilst selecting the wrong encoding scheme(ie. western-1252) in the browser

I have not evaluated a UTF-8 usage case.

Rolf Leggewie (r0lf) wrote :

guys, thank you for your testing and comments. At this point in time, that's really not necessary, though. It's known there is a problem. I think it's probably fair to say one cannot expect this will be resolved in one single upload, but will need testing after a patch has been proposed. Currently, there is no such patch to be evaluated on the table. Until that changes the comments are mostly noise, make the ticket harder to read and thus will slow down the resolution rather than helping it.

I kindly ask you to please refrain from commenting unless you want to propose a specific patch (in that case, I think it's better to just attach it to this ticket).

Yannis Tsop (ogiannhs) wrote :

using 7-zip it can be solved!

eg:
wget http://www.ops.gr/Ergorama/fileUploads/ypiresiaops/prokirikseis/biografiko.zip
LANG=el_GR.CP737 7z x -oPATH file.zip
convmv -r --notest -f utf-8 -t CP737 PATH/*

see proposed patch for package unp, same problem there:
https://bugs.launchpad.net/ubuntu/+source/unp/+bug/583417

167 comments hidden view all 198 comments

@Marcus: which is the second new library? unzip only needs librcc0.

librcc however requires librcd

Changed in unzip (Ubuntu):
assignee: nobody → Seung Soo Ha (sungsuha)
tags: added: regression-update
tags: added: needs-reassignment
167 comments hidden view all 198 comments
Rolf Leggewie (r0lf) wrote :

Seung, what is it you intend to do for unzip? Please don't assign to yourself without indicating what it is you want to do. What is it that makes you think this is not a bug in unzip or something that needs work in unzip? I have a pretty clear plan of action and unzip will need to be patched for that.

1) get libnatspec into Debian: http://git.debian.org/?p=collab-maint/libnatspec.git (help appreciated)
2) patch unzip (and others) to use libnatspec
3) evaluate results

@Rolf : Did you get my email?
In short, I asserted my intent to contact the original unzip maintainer on this issue.

Meanwhile, I have reviewed your plan and I believe that libnatspec is a viable solution.
Even so, it is my opinion that a patch should be pushed upstream(unzip).
That would be a permanent solution.

Thus, I believe there is reason to try to contact the original unzip maintainer.
If you believe that a reassignment(or un-assignment) is appropriate, please let me know.

For the time being, I think we should concentrate on efforts to "1. get libnatspec into Debian".
How is progress in that regard? What can I do to help?

Changed in gentoo:
status: Unknown → Fix Released
Changed in unzip (Mandriva):
status: Unknown → Confirmed
Alkis Georgopoulos (alkisg) wrote :

@Yannis T:
the method that you described didn't work for me in Lucid, here's a variant that did work:

wget http://www.ops.gr/Ergorama/fileUploads/ypiresiaops/prokirikseis/biografiko.zip
LANG=C 7z x -oPATH biografiko.zip
convmv -r --notest -f cp737 -t utf-8 PATH/*

Of course this is only a desperate solution, as it temporarily creates files with wrong encoding on the file system. But a desperate solution is still better than no solution at all.

Whenever the issue is fixed, please don't just put it in Lucid proposed, but in updates, as it's a significant regression for non-English countries.

Rolf Leggewie (r0lf) wrote :

Alkis, what's so difficult to understand about "comments unwelcome"? Your workaround may be posted in good faith but I again ask everyone to refrain from such postings! Post this on your blog, but please spare this ticket.

@Seung: By assigning to yourself you discourage others (including real devs) from picking up the problem. I'll unassign you. The things you want to do can be done without you being officially assigned this ticket. Judging your skill level from your mail and comments, I'm not sure there is much you can actually do to help. Anybody with the necessary packaging or programming skills won't need to ask but can jump right in. You're willingness to help out is appreciated, but to move this ticket further you need either packaging or coding skills. If you are interested to learn about packaging, you're more than welcome. Google for "debian maintainer guide" to get you started and hang around #debian-maintainers on OFTC.

So, ONCE AGAIN everybody please refrain from commenting unless you can either code or package debs! Thanks.

Changed in unzip (Ubuntu):
assignee: Seung Soo Ha (sungsuha) → nobody
Rolf Leggewie (r0lf) wrote :

@Seung, I agree that eventually the patch should be pushed upstream if possible. There may be an acceptance issue for this kind of patch. But this is really step 3 or 4 and we're still not even half-way through with step 1 (URL is posted above)

Changed in unzip:
status: Unknown → Invalid
164 comments hidden view all 198 comments

Update released for: librcc-devel, librcc0, librcc0-debuginfo, librcc0-debugsource, librcd-devel, librcd0, librcd0-debuginfo, librcd0-debugsource, rcc-runtime, rcc-runtime-debuginfo, unzip, unzip-debuginfo, unzip-debugsource
Products:
openSUSE 11.2 (debug, i586, x86_64)

Update released after a long testing phase in the test update channel.

Closing.

164 comments hidden view all 198 comments
Vladimir Mityukov (mityukov) wrote :

It seems to me (or, maybe, I've missed it) that nobody mentioned an option to manually select the charset for filenames in the archive. This option can be added e.g., to "Archive Manager" and so on (DE-specific tools).

I understand, that auto-detection is highly desired, but it's quite problematic, as far as I can see in this ticket. On the other side, I'm pretty sure, that manual selection option _itself_ would solve the problem for 60%+ of users. Others would find solutions (involving this new charset selector) over Internet. Currently, there are no answers (except of using windows/wine for un[re]packing, or quite complex approaches, like fuse-zip) even for advanced users, which I think is too bad.

Yannis Tsop (ogiannhs) wrote :

there is no such option neither in ark nor in file-roller

NickNeo (nickneo.one) on 2010-07-29
Changed in unzip (Ubuntu):
status: Triaged → Confirmed
Peter (pry) wrote :

Importance must be changed to critical!!! Do you realize how many potential clients we lost because of this bug?!

Rolf Leggewie (r0lf) wrote :

Pryguy, if you lost clients due to this bug, how about you pledge a bounty for this to be fixed? You're obviously making money off OSS-software, good thing! Maybe you can find others to join you and increase the bounty sum.

I'm working on fixing this, but I'm doing so in my free time. What have you done so far?

Rolf Leggewie (r0lf) wrote :

let me seize the opportunity to give a status update on what I've done and know about. Others are always welcome to help, but unless you can code or package, there currently is nothing you can do. Any comment not related to packaging or coding is STRONGLY discouraged (yes, I'm looking at you pryguy, have you even bothered to read this ticket?).

Next step in my opinion is to package libnatspec. Andrew and I are making good progress, albeit slowly: http://git.debian.org/?p=collab-maint/libnatspec.git I think the package is almost ready to be released to Debian (and possibly maverick). Please refer to the git repository to see where we are. Suggestions on that package welcome.

Peter (pry) wrote :

>Maybe you can find others to join you and increase the bounty sum.
Calm down please, already did this yesterday :)

Sergey Polushin (serbly) on 2010-08-02
Changed in unzip (Ubuntu):
assignee: nobody → Sergey Polushin (serbly)
Rolf Leggewie (r0lf) wrote :

Sergey, feel free to work on a solution. But don't assign to yourself. This sends the wrong signal of "somebody is working on this and it will be fixed soon" in your case.

Changed in unzip (Ubuntu):
assignee: Sergey Polushin (serbly) → nobody
Adrien Cunin (adri2000) wrote :

Hi,

From the tests that I've done, there are two different bugs about non-ASCII characters in filenames:
 * One reproducible with files created with zip on Linux: unzip shows broken encoding filenames but correctly extracts the files
 * Another reproducible with files created on Windows, probably due to the use if ISO encoding: unzip shows broken encoding filenames and extracted files have a broken encoding as well

I've managed to fixing the first one by compiling unzip with -DNATIVE.

Rolf Leggewie (r0lf) wrote :

Andrew and I have finished the work on a natspec package. We're now pushing that package into Debian and Ubuntu.

Requesting sponsorship for

https://launchpad.net/~r0lf/+archive/ppa/+sourcepub/1262565/+listing-archive-extra
http://revu.ubuntuwire.com/p/libnatspec

@Martin Pitt, I still think you have an obligation to undo the damage you've done, whether you work on the platform team or not. I'd be very pleased to see you picking up sponsorship of this package to see if we can fix the problem for good. Of course I wouldn't be angry at any sponsor if they beat you to it this time ;-)

Benjamin Drung (bdrung) wrote :

I am going to unsubscribe ubuntu-sponsors. ubuntu-sponsors is for sponsoring debdiff and there's not yet a debdiff for unzip. Rolf, please open a new bug report for getting libnatspec into Ubuntu (this bug is already long enough) and provide all information required for a FFe [1], because we passed feature freeze and an exception is required.

[1] https://wiki.ubuntu.com/FreezeExceptionProcess

The infozip team have recently spoken regarding the current state of unicode and unzip(most specifically the lack of the -O option)

They are preparing another release(6.1) and there is a thread discussing a potential fix for this matter[1]
I'm not sure if the libnatspec based patch could be a candidate for their release, but I lack the proper knowledge to contribute to the discussion there.
@Rolf: If you have not already, could you take a look at the thread?

[1] http://www.info-zip.org/board/board.pl?m-1248086794/s-45/

victorfuts (victorfuts) wrote :

        Peter Ryzhenkov wrote on 2010-07-31: #20
        Importance must be changed to critical!!! Do you realize how many potential clients we lost because of this bug?!

thats exactly what i wanna say.

Rolf Leggewie (r0lf) wrote :

Peter, so where is the bounty you pledged?

Peter (pry) wrote :

I've collected 20+ votes here. I can do a separate page for that on my web site also. Please contact me and let's discuss what is needed (my Jabber ID is in my contacts).

Murz (murznn) wrote :

Where can I add my vote to votes list?

Peter (pry) wrote :

Right on the page, click on the "This bug affects you and XXX other people".
:)

2010/9/9 Murz <email address hidden>

> Where can I add my vote to votes list?
>
> --
> unzip fails to deal correctly with filename encodings
> https://bugs.launchpad.net/bugs/580961
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (177929).
>

Rolf Leggewie (r0lf) wrote :

@Murz: not in the comments, click on "this bug affects me". Other than that, there is nothing you can do unless you can code or package.

@Peter:
 you on Aug 1st (quoting me):
>Maybe you can find others to join you and increase the bounty sum.
Calm down please, already did this yesterday :)

me (today):
Peter, so where is the bounty you pledged?

You (today):
fluff

IOW, you're all just hot air. No code, no money. Just strongly demanding freebies from others.

I urge you *once more* to abstain from substanceless comments so people like me who actually work on fixing this (first package is in the queue for Debian) can focus on the work. If you can't code but want to pledge money or pay someone to do this, you're more than welcome. Complaints, "this needs to have a higher priority" comments and indications you did something when that is not true are VERY unwelcome.

Peter (pry) wrote :

@Rolf I've added your contact. Have things to discuss. There are people from Russian Fedora that fixed the bug.

Peter (pry) wrote :

> Complaints, "this needs to have a higher priority" comments and indications you did something when that is not true are VERY unwelcome.
I'm sorry I've completely misunderstood you. I thought you were saying about votes, not the coding. I understand how it feels to get messages like mine, that are 'hot air' nothing more. Sorry again...

Murz (murznn) wrote :

http://sisyphus.ru/en/srpm/Sisyphus/unzip/patches - here you can get the patches, that solve problem in alt linux unzip version. Maybe we can apply it on ubuntu unzip?
http://dside.dyndns.org/darklin/portage/app-arch/unzip/files/unzip-ds-lazyrcc.patch - here is another patch.

Changed in unzip:
importance: Unknown → Medium
status: Invalid → Unknown
Sergei Ianovich (ynvich-gmail) wrote :

@Rolf
> first package is in the queue for Debian

Could you post a link to the patch(es) or even better debdiff?

@Yanovich
Is this what you're looking for?
http://git.debian.org/?p=collab-maint/libnatspec.git

144 comments hidden view all 198 comments

Still does not work in File Roller under OpenSUSE 11.3.

Created attachment 391041
file with problem

Created attachment 391042
screenshot of file roller

The same file (bug.zip) opens well with Ark from KDE3.

Created attachment 391043
the same file opened in Ark/KDE3

Works OK.

% unzip -l bug-540598_bug.zip
Archive: bug-540598_bug.zip
  Length Date Time Name
 -------- ---- ---- ----
    72704 09-20-10 23:11 Коммерческое предложение..doc
   388608 09-20-10 23:11 прайс на палатки и снаряжение14.09.2010.xls
 -------- -------
   461312 2 files

Open a bug against File Roller. No problem with unzip.

Does File Roller use unzip in this case?

It should use unzip. But I found an interesting bugreport:
https://bugzilla.gnome.org/show_bug.cgi?id=611257

Удалил p7zip. Теперь в File Roller все нормально, но встроенный просмотрщик архивов в КДЕ3 все равно показывает мусор (в Ark все нормально).

Removed p7zip. Now all OK in File Roller, but embeeded viewer in KDE3 still shows garbage (in Ark all OK).

Created attachment 391237
what I see in embeeded viewer

Same here. Krusader 1.90.0 shows file names correctly.
As you know, nobody interested to fix KDE3 bugs.

Maybe this bug is fixed in Trinity. If not, it is possible to make a bugreport.

155 comments hidden view all 198 comments
nandayo (casier) wrote :

Same problem here with a "é" in the directory name in the archive:

"checkdir error: cannot create PATHS_WITH_ACCENT
Invalid or incomplete multibyte or wide character"

:-/

Rolf Leggewie (r0lf) on 2010-10-15
Changed in ubuntu-jp-improvement:
assignee: Rolf Leggewie (r0lf) → nobody
Changed in gentoo:
status: Fix Released → Won't Fix
Click (clicky-mail) on 2010-11-16
Changed in unzip (Ubuntu):
assignee: nobody → Click (clicky-mail)
dr-ser (dr-ser) on 2010-11-18
summary: - unzip fails to deal correctly with filename encodings
+ распаковать не учитывает правильно с именами файлов
Aron Xu (happyaron) on 2010-11-18
summary: - распаковать не учитывает правильно с именами файлов
+ unzip fails to deal correctly with filename encodings
Alex Smirnov (coder1993) on 2010-11-18
Changed in unzip (Ubuntu):
assignee: Click (clicky-mail) → Alex Smirnov (coder1993)
tags: added: patch
Changed in ubuntu-jp-improvement:
status: Fix Committed → Invalid
Rolf Leggewie (r0lf) on 2010-11-30
Changed in ubuntu-jp-improvement:
importance: Undecided → High
status: Invalid → Fix Committed
Changed in unzip (Ubuntu Natty):
assignee: Alex Smirnov (coder1993) → Pinkertonik (pinkertonik)
Changed in file-roller:
importance: Unknown → Medium
status: Unknown → Confirmed
Chris Wilson (notgary) on 2011-01-14
Changed in hundredpapercuts:
status: New → Confirmed
Changed in unzip (Ubuntu Natty):
assignee: Pinkertonik (pinkertonik) → Canonical Desktop Team (canonical-desktop-team)
Martin Pitt (pitti) on 2011-01-28
Changed in unzip (Ubuntu Natty):
assignee: Canonical Desktop Team (canonical-desktop-team) → Brian Thomason (brian-thomason)
Changed in unzip (Ubuntu Natty):
status: Confirmed → Fix Released
Changed in gentoo:
importance: Unknown → Medium
Changed in unzip (Mandriva):
importance: Unknown → High
Changed in unzip (Ubuntu Natty):
status: Fix Released → Triaged
Martin Pitt (pitti) on 2011-02-25
Changed in unzip (Ubuntu Natty):
status: Triaged → Won't Fix
Chris Wilson (notgary) on 2011-04-02
Changed in hundredpapercuts:
status: Confirmed → Invalid
1l1a (1l1a) on 2011-04-05
description: updated
Justin Krehel (jkrehel) on 2011-04-09
Changed in linuxmint:
status: New → Triaged
Vova (vosha) on 2011-05-08
Changed in unzip (Ubuntu Natty):
assignee: Brian Thomason (brian-thomason) → Vova (vosha)
f-firefox (f-firefox) on 2011-05-12
Changed in unzip (Ubuntu):
status: Triaged → Fix Released
Changed in unzip (Ubuntu):
status: Fix Released → Triaged
f-firefox (f-firefox) on 2011-05-12
Changed in unzip (Ubuntu):
status: Triaged → New
C de-Avillez (hggdh2) on 2011-05-24
Changed in unzip (Ubuntu):
status: New → Triaged
Changed in unzip (openSUSE):
importance: Unknown → Medium
status: Unknown → Fix Released
tags: added: rls-mgr-o-tracking
tags: removed: rls-mgr-o-tracking
Mad_Loki (madloki1) on 2011-10-19
Changed in unzip (Ubuntu):
assignee: Brian Thomason (brian-thomason) → Mad_Loki (madloki1)
Changed in unzip (Ubuntu):
status: Triaged → In Progress
Changed in unzip (Ubuntu):
assignee: Mad_Loki (madloki1) → nobody
status: In Progress → Triaged
wert (wert-dmitrii) on 2011-11-27
Changed in unzip (Ubuntu):
assignee: nobody → wert (wert-dmitrii)
Changed in unzip (Ubuntu):
assignee: wert (wert-dmitrii) → nobody
Changed in unzip (Mandriva):
status: Confirmed → Unknown
Steve Langasek (vorlon) on 2013-02-10
tags: removed: regression-update
Chris Wilson (notgary) on 2013-02-22
no longer affects: hundredpapercuts
Пётр (plmak) on 2013-05-12
Changed in unzip (Ubuntu):
assignee: nobody → Пётр (plmak)
Пётр (plmak) on 2013-05-12
Changed in unzip (Ubuntu):
assignee: Пётр (plmak) → nobody
assignee: nobody → Пётр (plmak)
Adolfo Jayme (fitojb) on 2013-07-01
Changed in unzip (Ubuntu):
assignee: Пётр (plmak) → nobody
importance: High → Critical
no longer affects: unzip (Ubuntu Natty)
tags: added: verification-needed
Changed in unzip (Ubuntu Raring):
importance: Undecided → High
status: New → Fix Committed
Changed in unzip (Ubuntu Quantal):
status: New → Fix Committed
Changed in unzip (Ubuntu Precise):
status: New → Fix Committed
tags: added: verification-done-precise
Changed in unzip (Ubuntu Precise):
status: Fix Committed → Fix Released
tags: added: verification-done-raring
tags: added: verification-done-quantal
tags: removed: verification-needed
Changed in unzip (Ubuntu Raring):
status: Fix Committed → Fix Released
Changed in unzip (Ubuntu Quantal):
status: Fix Committed → Fix Released
Changed in unzip (Ubuntu):
status: Triaged → Fix Released
118 comments hidden view all 198 comments
Sebastian Geiger (lanoxx) wrote :

P.S.: I figured out correct code page for the `-O 850` option by opening the file in question on a windows machine which correctly unpacked the file, then I used the windows command line tool `chcp` to get the current code page on that windows machine:

>chcp
Active code page: 850
>

CSRedRat (csredrat) wrote :

Hendrik Knackstedt (hennekn) on 2014-02-02
Changed in unzip (Ubuntu):
status: Triaged → Fix Released

In 7z:
Pilot6 (hanipouspilot) wrote on 2014-10-18: #157
I created a new bug report regarding same problem with p7zip-full

https://bugs.launchpad.net/ubuntu/+source/p7zip/+bug/1382106

Yuan Chao (yuanchao) wrote :

Wouldn't it be better to patch file-roller to support encoding settings? Otherwise it still breaks if you get zipped file with different encoding from the default.

35 comments hidden view all 198 comments

This is an autogenerated message for OBS integration:
This bug (540598) was mentioned in
https://build.opensuse.org/request/show/39794 Factory / unzip
https://build.opensuse.org/request/show/40783 11.2 / librcd0
https://build.opensuse.org/request/show/40784 11.2 / librcc0
https://build.opensuse.org/request/show/40785 11.2 / unzip
https://build.opensuse.org/request/show/40799 11.2:Test / unzip

Changed in unzip (Debian):
status: Confirmed → Unknown
affects: unzip → ubuntu-translations
Changed in ubuntu-translations:
importance: Medium → Undecided
status: Unknown → New
no longer affects: ubuntu-translations
affects: gentoo → ubuntu-translations
Changed in ubuntu-translations:
importance: Medium → Undecided
status: Won't Fix → New
no longer affects: ubuntu-translations
affects: unzip (Mandriva) → ubuntu-translations
Changed in ubuntu-translations:
importance: High → Undecided
status: Unknown → New
no longer affects: ubuntu-translations
affects: file-roller → ubuntu-translations
Changed in ubuntu-translations:
importance: Medium → Undecided
status: Confirmed → New
no longer affects: ubuntu-translations
affects: unzip (Debian) → ubuntu-translations
Changed in ubuntu-translations:
importance: Unknown → Undecided
status: Unknown → New
no longer affects: ubuntu-translations
affects: linuxmint → ubuntu-translations
no longer affects: ubuntu-translations
Changed in unzip (Ubuntu Precise):
importance: Undecided → High
Changed in unzip (Ubuntu Quantal):
importance: Undecided → High
Mathew Hodson (mathew-hodson) wrote :

I've closed the remaining tasks. This particular bug was fixed in Precise and later. For remaining issues in p7zip and file-roller, see Bug #1382106 and Bug #495880

---------------
unzip (6.0-4ubuntu2) precise-proposed; urgency=low

  * Fix incorrectly displayed file names with UTF-8 characters.
    Add -DNO_WORKING_ISPRINT to build flags. (LP: #1199239, LP: #580961)
 -- Brian Murray <email address hidden> Wed, 06 Nov 2013 10:21:26 -0800

Changed in ubuntu-jp-improvement:
status: Fix Committed → Fix Released
tags: removed: needs-reassignment
Displaying first 40 and last 40 comments. View all 198 comments or add a comment.