Version: (using KDE Devel) Installed from: Compiled sources OS: Linux you can reproduce this bug quite simple: in a konsole do: $ mkdir A %A %%A %%%A $ konqueror . Konqueror now displays: A %A %A %%A Yes, it shows two directories with the *same* name. Seems there is something broken with escaping of special chars in filenames. I think thisone should be fixed before 3.4 release... -Marc
Ugh.. the %2f problem again... Confirmed on 3.4.0 RC1.
See http://bugs.kde.org/show_bug.cgi?id=97265 too (Stupid me reported that one earlier... but the otherone is unconfirmed...) IMO most important additional info from #97265 is: touch "a%2fb" results in "a/b" when displaying in konqui -Marc
*** Bug 97265 has been marked as a duplicate of this bug. ***
%2f being decoded as / is intentional. And that feature is what's causing this bug.
No! That must not be intentional IMO! If I have a file that is called "%2f" on the disk, then konqueror must display it as it is: %2f. Konqueror must always display filenames like they are. If you have a http URL with %2f than that of course has to be decoded as it is encoded. But a file on disk called "%2f" is not encoded... If I had a file called %2f on the web, then it will be encoded as %%2f (if %% == %...) What do you think how would one be able to rename a file %2f that is displayed as "/" ?? -Marc
It's intentional and has been a KDE feature for many releases now. %2f is always shown as / in Konqueror. Nowhere else, and URLs aren't especially encoded for it.
Can you please tell me who das developed such a "feature" (bug, imho)? This is not intended to be a flame... please read on ;) If I renamed a file foo into "bar/foo" I would expect the filemanager to try to move the file foo into the subdirectory called bar and not to call the file bar%2ffoo. If the subdir did not exist a good filemanager would ask me to create it for me.. To bork filenames in a filemanangers view is something I only thought M$ would be stupid enough to do, sorry. *Please* tell me one good reason for doing something like that? I bet that will be a security issue sooner or later, too because of the general possibility to fake filenames in KDE. At least it would be a good thing to have a config option like "Don't bork filenames" or something like that... AFAIK *any* character but a slash (/) and the nul byte (\0) are valid candidates for a filename or a part of it under unix/linux. I can tell you more examples to show that this in general looks like a bug: In konsole I can even use \n as part of the filename without problems: schiffi@homer:~/tmp$ touch "$(echo -e "foo\nbar")" Now try to view that in konqui: It does not decode that! What you can see is two half lines: the upper showing the lower half of foo and the lower showing the upper half of bar: is that intentional too? Now try some more newlines.... now there is a file without filename in konqui .. whohoo... (at least it looks like) And if one for whatever reason wants to name his files %%foo, bar%%%%% or foo%2bbar then he should be able do so because these are absolutely valid filenames on unix systems and it seems that no unix filemanager but KDE's "heart-app" can handle them without problems (I only tested mc and nautilus). Now beside that special %2f "feature": Would you call it correct behavior of konqueror to show two different files in exactly the same way so that the user cannot see any difference? Example: $ touch %foo %%foo Now I want to rename %foo to foo in konqueror. But which file do I have to rename to get the right one? funny game... Another question: Which behavior do you expect in konqui if you hit F2 on a file followed by hitting "Enter". I would expect it to *not* rename the file.. and at least it does it with files not containing any "magic" characters. Now why does konqui tell me that the file already exists when I try to rename of of these %foo files? *Please* think about that issue. I think that such a feature does not increase usability but puzzlement. And maybe we are talking about some different things here: A questionable "feature" and one or more real coding or usability bugs.
The escaping is used to make sure we can encode all filename everywhere. You are correct in that in Unix all characters but '/' is allowed, but that is all _representable_ characters. Which means we would be unable to save files with international characters from the internet on the local latin1 filesystem unless we escape them. To expand further; there are a completely different sets of characters in HTML or in URLs cannot handle, which are also escaped, it matches the policy of no loss of data. Now I like your examples of problematic filenames, please file separate bugs for them.
What do you mean by _representable_? IMO you will never have a problem to save a file locally that uses random us-ascii or latin1 characters. even if it was characters like \n or \t or \. Chars I talked about are all in the us-ascii charset. Why should us-ascii chars be encoded? And why should KDE allow a user to put (fake) the path directory seperater (/) into a filename.. this must lead to confusion as you may not be able anymore to distinguish between subdirectories and files in a directory (not in the views of konqui but maybe some other app trying to display files somehow) I think it is a good feature if konqui can decode encoded http URLs. But IMO it must not try to decode things like local filenames that are definitly not encoded. So there are many different protocols konqui can handle which are all (correct me If I am wrong) handled by special I/O-slaves. What is the problem of specifying which URLs (from which i/o-slaves) have to be de-/encoded and which not? To be de-/encoded: http Not to be de-/encoded: file / ssh / fish / iso / nfs (all that handle files on filesystems in some way..)
No, no. The *ONLY* especially encoded character is '/' and the reason for that is that it's one of the two characters that can't be represented in Unix filesystems. We do not especially-encode non-ASCII characters, nor do we especially-encode characters that some lame filesystems don't allow (e.g., FAT). The reason that is done is because some people expect / to be useable in filenames, like when they are ripping a CD and the music name, or artist, or whatever, contains a slash. As much as you think it's a misfeature -- and I agree with you -- there are some people who believe the contrary. Asking the feature to be removed will probably meet some resistance, and that from some KDE core developers. Now, *this* bug is about % being mis-represented. BTW, don't bother saying there could be two filenames who look alike, but aren't the same file. There are many ways to do that -- some of them legal, perfectly correct -- and we will not go fixing them all.
OK lets concentrate on the % thing. Now if there is no way to remove that %2f thing right now. How could this bug be fixed? I think it cannot be really fixed. IMO it could only be minimized. %2f has to be interpreted as "/" I think the cleanest way here then is to say that this cannot be escaped from within KDE because otherwise there will be many more problems... Means: %2f is *always* "/" in konqui regardless what chars are next to that sequence. If you try making %2f escapable with %%2f for examnple then you have the problems that now occure. So %%2f would simply be interpreted as %/, not as %2f I think then it will be "fixed" for now, right?
There should be exactly two sequences being interpreted differently, IMO: %2f = '/' %%2f = '%2f' Nothing else should, so '%%' should still be '%%', and I'd consider this bug solved.
*** This bug has been marked as a duplicate of 51306 ***