GNOME Bugzilla – Bug 492134
If you press "~" in the "Location" bar, gtk replaces it with an invalid directory.
Last modified: 2008-04-02 16:58:52 UTC
[ forwarded from http://bugs.debian.org/448675 by "Brandon" ] To reproduce (using leafpad, or iceweasel, or most gtk apps with a FileChooser): 1) Open leafpad (or other) 2) Press Ctrl-O to Open a File 3) Press Ctrl-L to activate Location bar. 4) Press ~ My Location bar now says "wk/". Yours probably says something similar, but with your login name. 5) Now press Enter. Error message: "The folder contents could not be displayed. Error getting information for '/home/wk/wk': No such file or directory" ~ activates the wrong folder. It should be /home/wk, but instead, is /home/wk/wk. Clearly incorrect behavior. ----- Note that to reproduce this, you need to use the gtk+ backend; this bug doesn't occur with the gnome-vfs backend. It may also be related to bug#132500.
*** Bug 517880 has been marked as a duplicate of this bug. ***
*** Bug 497290 has been marked as a duplicate of this bug. ***
Could someone take a look at this, it's probably not that hard to fix, but only for those who has experience with the code.
I noticed that if i delay the expansion by quoting it first, i get the proper thing. So "~/" expands properly, "~" doesn't, so there is a race condition of two systems somewere.
A great deal of substitution code exists, why not keep the ~ and just evaluate it like that?
The problem is in gtk+/gtk/gtkfilesystemunix.c:gtk_file_system_unix_parse(). It seems to be a bit overzealous in substituting "~" for the user's home.
Could you try to fix it?
Created attachment 107711 [details] [review] Avoid early substitution. This fixes the bug for me.
Bump. Could someone apply the patch (or refuse with good reason).
Another bump, could the assignee please respond.
(In reply to comment #8) > Created an attachment (id=107711) [edit] > Avoid early substitution. > > This fixes the bug for me. First, can you please produce patches with diff -up in the future, so function context is readily available when reading it? As for the patch itself, treating '~' like '' in tilde expansion looks wrong to me. If at all, i'd have expected '~' to be treated like '~/' (for which there is proper home dir expansion code in place). I guess we indeed have to wait for Federico to review the proper fix here though. (replying because of nagging on IRC)
This patch avoids doing that, it ensures that it doesn't try to substitute the path, until two characters are present. If that 2nd character happens to be a slash, then it will substitute that, otherwise not. Or were you referring to substitution code elsewhere?
(In reply to comment #12) > This patch avoids doing that, it ensures that it doesn't try to substitute the > path, until two characters are present. If that 2nd character happens to be a > slash, then it will substitute that, otherwise not. Or were you referring to > substitution code elsewhere? no, i'm saying i don't see why '~' should be treated any differently from '~/'.
(In reply to comment #13) > no, i'm saying i don't see why '~' should be treated any differently from '~/'. Because ~joe/ is different from ~/.
(In reply to comment #14) > (In reply to comment #13) > > no, i'm saying i don't see why '~' should be treated any differently from '~/'. > > Because ~joe/ is different from ~/. i meant terminated strings. to make it overly clear, i don't see why "~\0" should be treated any different from "~/\0". i'm *not* talking about "~SOMEUSERNAME".
The problem is that entering a single character already gives "~\0", this is too soon and and on top of that it's not properly substituted. So waiting for the second character seems like a good idea.
Created attachment 108478 [details] [review] gtk+-bgo492134-gtkfilesystemunix-tilde-expansion.diff I've committed this to trunk and gtk-2-12. gtk_file_system_unix_parse() was splitting "/home/username" from expand_tilde() into path="/home" and file_part="username", which is not whatthe caller wants. Here we ensure that expand_tilde() returns slash-terminated strings if we have an empty basename, as in "~" or in "~username". 2008-04-02 Federico Mena Quintero <federico@novell.com> Fix http://bugzilla.gnome.org/show_bug.cgi?id=492134 - The file chooser incorrectly substitutes and expands a ~ when you type it in the filename entry. * gtk/gtkfilesystemunix.c (expand_tilde): Ensure that empty basenames result in a slash-terminated pathname. gtk_file_system_unix_parse() is correct, but it was splitting "/home/username" into path="/home" and file_part="username", which is not what the caller wants when the entry has just "~" or "~username". 2008-04-02 Federico Mena Quintero <federico@novell.com> Fix http://bugzilla.gnome.org/show_bug.cgi?id=492134 - The file chooser incorrectly substitutes and expands a ~ when you type it in the filename entry. * gtk/gtkfilesystemunix.c (expand_tilde): Ensure that empty basenames result in a slash-terminated pathname. gtk_file_system_unix_parse() is correct, but it was splitting "/home/username" into path="/home" and file_part="username", which is not what the caller wants when the entry has just "~" or "~username".