Version: unspecified (using KDE 4.4.3)
The much maligned bug which prevents non UTF-8 encoded filenames 165044 https://bugs.kde.org/show_bug.cgi?id=165044 means that any files generated with an invalid encoding can not be accessed, modified, renamed or anything under kde4 due to a QT limitation. Ark, when extracting from an archive with a non UTF-8 encoding (such as a zip file encoded in japanese encoding) will extract files with invalid names, rendering a directory and/or series of files that can then not be accessed with any standard kde application. Presumably this is because it uses (un)zip as the backend for extraction. I suggest using an application for extraction that automatically converts filenames to valid UTF-8 encoding, even if the filename is different. 7z does this.
Steps to Reproduce:
Extract a zip archive encoded with non UTF-8 encoded filenames.
Creates files and directories visible but inaccessible in dolphin or konqueror.
Files and directories should be accessible, even if the filenames are now different.
Hmm. We already have a 7zip plugin, which is currently used only for 7zip files. There's a wish for letting the user choose which backend to use for each archive format, but for now we could try giving the 7zip plugin more priority than the infozip one for zip files so that it is used instead by default.
What do you guys think?
If 7z supports all the standard archive formats without the encoding problems, why bother using multiple backends at all by default?
One possible downside I see here, though, is that 7zip apparently cannot handle multi-volume archives.
Created attachment 48742 [details]
Prioritizes p7zip over unzip & unrar
What this patch does:
- Fixes cli7z plugin to support rar files.
- Gives cli7z a higher priority than zip / rar plugins.
Why this is good:
- p7zip doesn't create invalid filenames which we can't handle in KDE.
- p7zip is way faster than unzip / unrar.
What still needs to be done:
- Detect if p7zip and the p7zip-rar plugin are installed and default to unrar / unzip otherwise.
this does still happen in 4.5 with .zip files
*** Bug 251206 has been marked as a duplicate of this bug. ***
The same problem with polish characters: ą, ę, ó, ł, ś, ź, ż, ć, ń. Ark either doesn't extract a file, or extract inaccessible and not-to-remove file. Version 2.15.
Changing the default assignee in the currently open Ark bug reports to me.
The problem exists in zip files created with old versions of winzip, pkzip or infozip for windows. There are a lot of patches for the latest version of the unzip utility from info-zip that add two new switches (-I and -O) that allow you to specify the character set to be used. As it seems in the latest beta version one of those patches has been included (v6.1beta). It would be nice if ark could use those flags somehow to specify the correct character set to be used for extraction and listing.
*** Bug 266158 has been marked as a duplicate of this bug. ***
Comment 2 in bug 266158 lists a few bug reports related to unzip itself, I'm adding them here not to lose track of them.
*** Bug 276210 has been marked as a duplicate of this bug. ***
*** Bug 304426 has been marked as a duplicate of this bug. ***
*** Bug 308596 has been marked as a duplicate of this bug. ***
I do not think this issue is due to zip/unzip: same problem with valid UTF8 filenames.
Steps to reproduce:
zip foo.zip abcdé.txt
LC_ALL=fr_FR.UTF-8 ark foo.zip
-> the file appears as abcd?.txt and a double click to open it fails with error message:
"Impossible de charger le fichier /tmp/kde-fred/arkDVVZUI//abcd?.txt car il n'a pas été possible de lire depuis celui-ci. Vérifiez si vous avez les droits d'accès à ce fichier." Which I can translate to "Not able to load file /tmp/kde-fred/arkDVVZUI//abcd?.txt because it was not possible to read from it. Check if you have the permissions to access this file."
The funny thing is that with the C locale, it works better:
LC_ALL=C ark foo.zip
-> the file appears as abcd#U00e9.txt and is extracted as that name. Double clicking on it is ok to open it.
é unicode is e9 but ark should not convert the name to abcd#U00e9.txt. Whatever the locale, the name should contain "e cute".
Hope this helps to solve this bug.
Ark is also not extracting files when they can't be written on disk because of filesystem limitations (and probably also permissions, didn't check). This wouldn't be much of a problem if only Ark didn't fail silently. I've lost data due to the fact that I deleted the original zip files after uncompressing them. Several files lost because of funny characters in their names. Not much of a problem, I had the data resent to me but this might not always be the case and renders Ark as an unreliable program, especially in mixed environments. You should never be in doubt about whether the operation was successful or not.
Having the possibility to rename said files from within Ark would also be very nice.
*** Bug 323098 has been marked as a duplicate of this bug. ***
*** Bug 345519 has been marked as a duplicate of this bug. ***
*** Bug 349577 has been marked as a duplicate of this bug. ***
*** Bug 329573 has been marked as a duplicate of this bug. ***
Since this is a abandoned software and not developed anymore, I recommend to everyone encountering this issue - to download and use PeaZip. Better and nicer UI, too. And it works!
Ark has actually seen quite a lot of development this year. I recommend you to try a recent release. We are working on fixing this bug for the 15.12 release in December.
(In reply to Dan Duris from comment #22)
> Since this is a abandoned software and not developed anymore, I recommend to
> everyone encountering this issue - to download and use PeaZip. Better and
> nicer UI, too. And it works!
And it's also not shipped by any major distribution.
Please do check for facts before making any claim. Ark is not abandoned and it's actively maintained.
Sorry to insult your feelings, but I haven't seen upgrade to Ark for few years and not talking about the basic usability issues of the utmost importance - UTF8 handling of characters.
BTW, you know as well as anyone, that UTF8 has been around for 15+ years, so there is no excuse Ark can not handle it yet.
It's basic unusable for any work with UTF8 right now and based on UTF8 prominence, let's just make it short: it's unusable.
(In reply to Dan Duris from comment #25)
> Sorry to insult your feelings, but I haven't seen upgrade to Ark for few
> years and not talking about the basic usability issues of the utmost
> importance - UTF8 handling of characters.
> BTW, you know as well as anyone, that UTF8 has been around for 15+ years, so
> there is no excuse Ark can not handle it yet.
> It's basic unusable for any work with UTF8 right now and based on UTF8
> prominence, let's just make it short: it's unusable.
You're talking about one specific plugin (zip) among many others wich have good UTF8 support. The fact that UTF8 is broken in the zip plugin does not imply that Ark is not developed anymore. In fact, for the next Ark release we are trying to switch to the pz7ip plugin for zip archives, in order to solve this and other related bugs.
I'm sorry to hear that Ark cannot help you with the work you do, but really, you should blame the info-zip developers more than us, for this specific issue.
Sorry to remind you all, but this is for bug reports, not for discussions. If you want to attack/defend/anything else not purely bug related, please do so somewhere else. It will help the maintainers and all who have subscribed to this bug.
Git commit 50916c0ff9fd6731fc2effa26551e7f92b595eba by Elvis Angelaccio.
Committed on 03/10/2015 at 15:56.
Pushed by elvisangelaccio into branch 'master'.
Set cli7zip as the default plugin for zip archives
This increases the priority of the cli7zip plugin, so that p7zip is now the
default backend used for zip archives handling.
This change was required to address the unicode issues of the clizip plugin,
which resulted in a lot of bugs. While not perfect, p7zip handles better
filenames with non-ASCII characters; in particular it never extracts files
which cannot be opened or not even deleted by Dolphin.
Distributions who ship a patched version of Ark to address the same problem
(e.g. by setting libarchive as default plugin for zips, as Debian/Kubuntu do)
should drop their downstream patches, since they should not be necessary anymore.
M +1 -1 plugins/cli7zplugin/kerfuffle_cli7z.desktop.cmake
*** Bug 319712 has been marked as a duplicate of this bug. ***
*** Bug 322100 has been marked as a duplicate of this bug. ***
*** Bug 220513 has been marked as a duplicate of this bug. ***
*** Bug 355814 has been marked as a duplicate of this bug. ***