Bug 205493 - issues with spaces and special chars in filenames
Summary: issues with spaces and special chars in filenames
Status: RESOLVED DUPLICATE of bug 165044
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 16.12.2
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Peter Penz
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-28 15:31 UTC by arne anka
Modified: 2009-08-31 12:26 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description arne anka 2009-08-28 15:31:53 UTC
Version:           1.3 (using 4.3.00 (KDE 4.3.0), Debian packages)
Compiler:          cc
OS:                Linux (i686) release 2.6.28

copying, moving or renaming files with space or special chars in their names does not work.
on the commandline i'd had to escape those chars and spaces -- but from an entirely graphic tool like dolphin i expect that to be done automatically, instead of popping up an error dialog and refusing to do anything about that.
Comment 1 arne anka 2009-08-28 15:54:58 UTC
example filename:
Chitz, Arthur - Archiv Staatsschauspiel Dresden und Agata Schindler, Dresdner Liste (Notenbeispiel Trilltrall und seine Brüder).jpg
Comment 2 Frank Reininghaus 2009-08-28 21:14:35 UTC
Thanks for the bug report! I created a file with that name, selected it in Dolphin 4.3.0, pressed F2, entered a new file name and pressed Enter. That worked fine for me.

Can you actually open that file if you click it in Dolphin? If that does not work and fails with an error message like "The file does not exist", the file name might have a broken encoding (see bug 165044).
Comment 3 arne anka 2009-08-31 11:36:10 UTC
dolphin shows the ü in Brüder as a black diamond with a questionmark in it.
trying to rename indeed produces that "does not exist" message.
so, it looks like it matches 165044.
the file lives on a still working production server (aix), it was put in a zip archive by
Zip 2.3 (November 29th 1999).
and unzipped on my linux, debian/sid host with
UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.

so -- scenario is pretty much the same 165044 refers to. but the stance Thiago Macieira took up, is in no way helping (and by popular vote clearly invalidated).
what am i to do now?
Comment 4 Frank Reininghaus 2009-08-31 12:26:41 UTC
Thanks for the update! I'll mark it as a duplicate of the other bug then.

> so -- scenario is pretty much the same 165044 refers to. but the stance Thiago
> Macieira took up, is in no way helping (and by popular vote clearly
> invalidated).

I understand that you and other users are unhappy with the situation, but as pointed out by Thiago, this is actually a bug in unzip, and it would require a huge amount of effort to work around this issue in KDE (because Qt does not support files with non-Unicode file names). Thiago mentioned that another option would be a program that repairs file names with broken encoding, but someone who is interested in this issue and who has a lot of free time would have to volunteer to write such a tool (that's how free software works, after all).

> what am i to do now?

I'm afraid the only thing you can do (unless you are willing to develop the mentioned file name repair-tool) is to rename the broken files in a shell or using some other program that can handle file names with broken encoding.

You could also report a bug to the developers of the program that created the files (i.e., unzip).

I'm sorry that I can't offer you anything else :-(

*** This bug has been marked as a duplicate of bug 165044 ***