GNOME Bugzilla – Bug 318999
Nautilus and famd fail to handle symlinked paths
Last modified: 2005-11-27 11:34:47 UTC
Distribution: Slackware Slackware 10.2.0 Package: nautilus Severity: critical Version: GNOME2.12.1 2.12.x Gnome-Distributor: Dropline GNOME Synopsis: Nautilus and famd fail to handle symlinked paths Bugzilla-Product: nautilus Bugzilla-Component: general Bugzilla-Version: 2.12.x Description: Description of Problem: If I go to a directory in Nautilus via a symbolic link, the famd updates never happen, and/or Nautilus crashes whenever the directory changes. It also seems to be triggered if I view the properties of a audio or video file, but only occasionally, and that might be a seperate issue. For example, I have a link on my desktop called "gtkgnutella" which is a link to /u/downloads/gtkgnutella. If I open gtkgnutella with Nautilus, the path shown in Nautilus is "$HOME/Desktop/gtkgnutella. As files are added to this directory, Nautilus either never shows the updates, or it crashes when the updates occur. However, if I specifically go to /u/downloads/gtkgnutella, then there are no crashes and the view updates as expected. It seems that either Nautilus or famd or both cannot handle viewing directories via a symbolic link. I have also had occasional "Not the same filesystem!" errors when deleting files from a symlinked path, which might be related. Aside: I think that Nautilus should jump to the pointed-to path instead of using the symlink path anyway, as I use symlinks as shortcuts in Nautilus, not alternate paths. Steps to reproduce the problem: 1. create a link on the desktop to some path 2. open the symlink in nautilus 3. have some program update the directory Actual Results: Expected Results: How often does this happen? Additional Information: ------- Bug moved to this database by unknown@gnome.bugs 2005-10-16 02:42 UTC -------
See Bug 318303 regarding "symlinks as shortcuts" And the famd nautilus symlink issue is indeed a mess, I gave up and moved to gamin, where, as long as you don't use inotify, it works fine. However! If you do use inotify (which is the preferred way), you get the same broken behaviour as inotify specifically refuses to monitor symlinks and assumes it is up to Nautilus to resolve the symlink first. I'm going to file a seperate bug on this because it is clearly a problem of Naut.
My previous comment was slightly inaccurate - it is up to GAMIN to resolve symlinks completely before using the paths with inotify.
Looking at #173179 I am not sure I agree here. Why I also suffer from the above problem (symlinked Desktop + gamin + inotify) I feel that gamin must somehow also be able to monitor symlinks, i.e. if 'l' was a symlink 'monitor l' should monitor whether the link now points to a different location or gets erased. So I am not sure whether either gamin needs a monitor_target() or the client has to resolve the link...
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of 322348 ***