| Summary: | "New folder" dialog results in unhelpful error message when creating a folder named as "~" | ||
|---|---|---|---|
| Product: | [Applications] dolphin | Reporter: | Travis Evans <travisgevans> |
| Component: | general | Assignee: | Peter Penz <peter.penz19> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | adaptee, faure, finex, frank78ac, lex.lists, markg85, rakuco |
| Priority: | NOR | ||
| Version: | 2.1 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Travis Evans
2005-12-01 23:45:29 UTC
confirming for 3.5.5 confirmed for 4.0.4 Come to think of it, I think what happens is that it tries to interpret '~' as the user's home folder when it shouldn't. For instance, if I right-click the desktop and choose New Folder, and then enter something like '~/New', it actually creates a folder called 'New' in the root of my home folder instead of on the desktop. And if I enter '~New' instead, it gets confused. I played with it some more--it works just like in Bash. If you enter '~Foo', it really tries to create '/home/Foo' and (most likely) fails. This is where the strange error messages are coming from. I'm not sure whether this is what the developers intended, especially from KDesktop's New Folder dialog. Moved to dolphin: this behaviour is still reproducible and now the file management is done by dolphin. I don't know what could be the better solution of this situation. '~testfolder' is actually a short-hand notation for the home directory of the user 'testfolder'. If a user with that name exists, even bash refuses to create a directory named '~testfolder' in my home directory. Probably that's related to the problem. Yes, it appears that in Bash, if I try to create a directory named "~user" where "user" is the name of a user on the system, it fails; otherwise it succeeds. In KDesktop, if I use a user name, I get a different message (either access denied if the user's home directory doesn't exist, or folder exists if it does), but the message I originally reported if it's anything else. Also, the former two errors do display the name or path of the directory it's trying to create which helps to understand what it's doing, but in the latter case, it gives no clue. Come to think of it, on KDE 3.5.10 (yes, I really need to upgrade one of these days), the message seems to have changed to "Could not make folder ." with a space before the ending period. I'm not sure if this is a typo or because it's trying to display a folder name or something at the end but getting a null string somehow. Issue confirmed in KDE 4.5.0 and it's a bug. Why? If you type this on the console: mkdir "~" (with the quotes!) then it just creates the folder like expected and in the current location like expected. Dolphin sees the folder just fine and enters it just fine. It's just the making it is the problem. And i made a patch for it : http://reviewboard.kde.org/r/5186/ Just a simple one liner. SVN commit 1174616 by adawit: - Allow the creation of files/directories that start with "~". BUG:117473 M +9 -2 knewfilemenu.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1174616 Any intention to backport? @Dawit, Thank you for patching it. i was actually gonna make a new attempt today.. I kinda forgot about this issue the last few days. @Raphael I don't think this will be backported or is _that_ important to be backported. I rather fix bugs then backporting existing fixes that end up in kde 4.6 anyway. Well, IMO if it is a bug fix and does not introduce new strings or a big amount of untested code, it does not matter if it is deemed important or not -- just backport it. As for fixing bugs rather than backporting, I don't see how one excludes the other. SVN commit 1174761 by adawit:
- Make the previous commit r1174616 work for file names as well. Now using escaped
tilde mark ("\~") works properly when creating filenames as well.
CCBUG:117473
M +17 -11 knewfilemenu.cpp
WebSVN link: http://websvn.kde.org/?view=rev&revision=1174761
Just tested it out again and making a new folder with just "~" is still resulting in: "A folder named <users home folder> already exists." Thus the bug is not resolved. However, making a new folder and typing: "\~" is working and makes a folder with the name: "~" but that's not what this bug is about and not something you can expect the user to know (adding a "\" before "~"). I confirm the initally reported bug has been fixed and I also confirm that creating a directory with only "~" still return the error. (In reply to comment #15) > Just tested it out again and making a new folder with just "~" is still > resulting in: "A folder named <users home folder> already exists." IMHO, this is expected behaviour. That folder really does exist, doesn't it? And it's also consistent with what bash does.(In reply to comment #15) > However, making a new folder and typing: "\~" is working and makes a folder > with the name: "~" but that's not what this bug is about and not something > you can expect the user to know (adding a "\" before "~"). Also consistent with bash, therefore, I consider this issue resolved. |