GNOME Bugzilla – Bug 59607
Unwanted symlinks resolution in file selector
Last modified: 2007-04-01 00:45:40 UTC
I've originally submitted this bug to xmms.org (#249), but they claim it to be Gtk+ problem. The problem is that when file selector encounters a symlink to directory, at some moment it resolves the link. This is a *big* problem in case of automounted NFS filesystems. This happens with XMMS, so the following explanation is XMMS-specific (but the bug will definitely affect all other apps). Consider the following situation: there's a server machine ("mp3arc") which exports a directory with mp3s (let it be /home/mp3) over NFS. And a client machine, which runs "amd" automounter, providing access to NFS volumes via /net/HOSTNAME. In this case it would be "/net/mp3arc/home/mp3". Amd handles accesses to /net/HOSTNAME/DIR by mounting required filesystems to /.automount/HOSTNAME/root/DIR and providing a symlink /net/HOSTNAME->/.automount/... After some period of inactivity (300s by default) Amd does an umount and access to /net/HOSTNAME is required to mount again. But XMMS tries to remember a *resolved* path (i.e. /.automount/mp3arc/root/home/mp3/...), which becomes invalid soon, instead of correct /net/mp3arc/home/mp3/..., which it was pointed to. So, files in playlist become unavailable. Using dirs other than /net (e.g. we use permanent /export/HOSTNAME->/net/HOSTNAME/INTERESTING-PATH) changes nothing, since the path is always resolved to /.automount/... This "intelligent" link following is definitely a bug, since symlinks are handled by the kernel and it isn't app's business to check them (except a very few progs like MC, where this feature is also very questionable). What is even more weird is that resolving doesn't occur when clicking on symlink to directory, but when clicking on ".." inside.
The internals of GtkFileSel are a lot more complicated than you might expect and this isn't at all easy to fix. A rewrite is planned for GTK+-2.2
Setting the priority to "Low" for all bugs related to GtkFileSelection. This has been deprecated in favor of GtkFileChooser.
Resolving WONTFIX all RFE's for the old file selector.
hi all, though i'm not closely aware of the move from gtkfilesel to gtkfilechooser, this misfeature still manifests today. i'm pasting here a small testcase that clearly reproduces this, even with gtk 2.10. this is the bottom line of the conversation between me and Sven Arvidsson <sa@whiz.se>, which is debian maintainer for gtk+. On Wed, 2007-03-21 at 01:20 +0200, alex bodnaru wrote: > > the problem is not very specific to my system. > > > > to reproduce it, create an user account, and move his /home/username > > contents to /somewhere-else. > > > > then symlink /somewhere-else to /home/username, login username, and > > activate gtk/gnome applications, add icons to panels etc. > > > > last, logout the user, and grep in /home/username for the string > > "/somewhere-else". if you find it anywhere, the problem still exists. Hi, I can still reproduce this with GTK+ 2.10. The only upstream request for this I have found is this bug, closed almost three years ago. http://bugzilla.gnome.org/show_bug.cgi?id=59607 If this still is a problem I suggest you file it in GNOME Bugzilla for product "gtk+" and component "general". You can make a reference to the bug I mentioned above as it was filed for GTK 1.2. -- Cheers, Sven Arvidsson