GNOME Bugzilla – Bug 593809
Nautilus does not restore the position of the icons on the desktop when they are symbolic links
Last modified: 2009-11-26 15:08:47 UTC
Icons represented symbolic links on the desktop are rearranged every time nautilus is restarted. It looks like their position is not saved anywhere. The exception is symbolic links to files already present in the desktop. They appear in the same position as the file this points to.
The easiest way to observe this is simply to position a symbolic link icon anywhere on the desktop then press ctrl-r, the icon will go back in the top left corner.
This is due to gvfs reporting symlink target metadata when NOFOLLOW_SYMLINK is not specified (which nautilus doesn't). However, this is not really right for metadata. Metadata is per path (e.g. when setting it), so we should not report it for the target but the symlink.
Fixed in glib master.
The issue is still present with glib 2.22.1 (with mentioned "fix")
It seems that gvfs fails to report correct metadata for a symlink when the devices of the symlink and its target are different. I looked the patch. statbuf.st_dev refers to the device of the target file. Isn't that a culprit? | vfs = g_vfs_get_default (); | class = G_VFS_GET_CLASS (vfs); | if (class->local_file_add_info) | { | class->local_file_add_info (vfs, | path, | statbuf.st_dev, | attribute_matcher, | info, | NULL, | &parent_info->extra_data, | &parent_info->free_extra_data); | }
I don't know what info class->local_file_add_info adds to what, but went ahead anyway and modified the above so that the local_file_add_info won't receive device for the symlink target. It fixed the problem without any apparent ill effect. diff --git a/gio/glocalfileinfo.c b/gio/glocalfileinfo.c index 0a063e9..106d5f6 100644 --- a/gio/glocalfileinfo.c +++ b/gio/glocalfileinfo.c @@ -1432,6 +1432,7 @@ _g_local_file_info_get (const char *basename, char *symlink_target; GVfs *vfs; GVfsClass *class; + guint64 device; info = g_file_info_new (); @@ -1483,6 +1484,8 @@ _g_local_file_info_get (const char *basename, g_free (display_name); return NULL; } + + device = statbuf.st_dev; #ifdef S_ISLNK is_symlink = S_ISLNK (statbuf.st_mode); @@ -1711,7 +1714,7 @@ _g_local_file_info_get (const char *basename, { class->local_file_add_info (vfs, path, - statbuf.st_dev, + device, attribute_matcher, info, NULL,
I'm seeing this problem as well, symlinks are always rearranged no matter how I dispose them. The assumed positions depend on the number of symlynks presents and their names but I can't seem to find a rule to explain the changes: for example, A, B, C and D stay where I put them as long as symlink E to /path/to/E is there, if I remove E or rename it, then C starts jumping around.
Yeah, I am experiencing the same issue (as Giacomo Perale) since I updated to Ubuntu 9.10 and I think it is quite ANNOYING as I mostly use links on my Desktop.
Well maybe not exaclty like Giacomo Perale but something like this. Also I tried what Takehibo Abe suggested and it doesn't seem to fix it either. Futhermore, I want to add that since my upgrade to Karmic when I create symlinks on the desktop they are placed somewhere else than they shoud be (not where the mouse was). I think this might be related too.
> Well maybe not exaclty like Giacomo Perale but something like this. > Also I tried what Takehibo Abe suggested and it doesn't seem to fix > it either. hmm.. It works for me. We may have different problems. I'm running debian unstable. The offending debian package is liglib2.0-0 version 2.22.2-2. It includes the change made in commit: http://git.gnome.org/cgit/glib/commit/?id=6f1ce483eb136159f42b7dde3aa4466ba3e874c1 It works for the symlinks whose target is on the same device as the symlink itself but fails for those that are on a different device. I observed the same behavior in Fedora 12 beta. Anyways, why does this bug remain marked as fixed and resolved?
So your fix won't work for symlinks that point to other devices? Well that would explain it because my symlinks on the Desktop are mostly pointing to another device. Btw.: I agree: Why is this bug marked as fixed when it obviously isn't fixed?
Do you have any idea how to fix it for symlinks on other devices as well? It also explains why a few symlinks stayed at their position - because they were at the same device...
(In reply to comment #11) > So your fix won't work for symlinks that point to other devices? Well, my fix works (at least for me). What does not work is the fix done in http://git.gnome.org/cgit/glib/commit/?id=6f1ce483eb136159f42b7dde3aa4466ba3e874c1 If you check the source, you'll see that it passes the device id of the target to the function named class->local_file_add_info while it passes pathname of the symlink itself to the same function. My patch fixes that. I do not know how class->local_file_add_info works. So it is a quick&dirty i-dont-know-what-im-doing kind of patch, but it seems to work.
Is there a pre-compiled package that includes your changes? Because maybe I did something wrong. After all I just tried it fast, could be that I made some mistake or something similiar.
> Is there a pre-compiled package that includes your changes? No. > Because maybe I did > something wrong. After all I just tried it fast, could be that I made some > mistake or something similiar. I tried to build from the git.gnome.org source at fist but it did not work well. So I built from debian source with debian utilities. apt-get source libglib2.0-0 apt-get build-dep libglib2.0-0 modify source -- gio/glocalfileinfo.c debuild -us -uc (or dpkg-buildpackage -us -uc) I guess the steps are same for ubuntu. hth
Thanks for your tip with using those utilities because NOW it works. Links are stored perfectly and what is more when I create a link it is placed at the position I created it - didn't work correctly before either. HOWEVER, this still doesn't explain why this bug is marked as "resolved fixed" because this change isn't commited into the source-code (yet).
In latest Ubuntu karmic i've to rebuild libglib2.0-0 with Takehiko Abes patch to solve the problem. Thx!
(In reply to comment #13) > If you check the source, you'll see that it passes the device id of the > target to the function named class->local_file_add_info while it passes > pathname of the symlink itself to the same function. My patch fixes that. > > I do not know how class->local_file_add_info works. So it is a quick&dirty > i-dont-know-what-im-doing kind of patch, but it seems to work. Takehiko, your patch is basically right, though it's not an universal solution. I've tested it and confirming as working, having my /home on different partition than the symlink target. The inter-class call local_file_add_info() leads to g_daemon_vfs_local_file_add_info() which only adds metadata at the moment. But that can change in future so I'd be tempted to add comment at least with a warning. This function has been introduced just for metadata and I think it's not a big deal. But let Alex have a look before committing. Metadata are stored separately for each device, even though we passed correct path (to symlink itself, see last commit), it ended up in a different metadata database.
(In reply to comment #18) > This function has been introduced just for metadata and I think it's > not a big deal. But let Alex have a look before committing. Yes. That's good. Thank you!
Yeah, that patch seems right. Commited to master and glib-2-22. tomas: Yeah, the api is sort of broken and should really have passed in both symlink and target + the follow_symlink flag. However, its only used by metadata which doesn't follow symlinks, so lets ignore that for now.