On Mon, Jul 27, 2009 at 1:31 AM, Tomas Bzatek<tbza...@redhat.com> wrote: > On Sat, 2009-07-25 at 22:24 -0700, Mike Rooney wrote: >> The use case I am trying to solve is when nautilus is viewing a directory >> which is a >> symlink to A, and then becomes symlinked to B. Nautilus doesn't >> realize it isn't viewing the correct directory anymore so I need a way >> to tell it to re-visit the same address to get to the new location. >> This comes up often when working with encrypted directories or >> partitions which are often layered filesystems dealt with through >> symlinks. So if I want to have a nautilus extension to encrypt or >> decrypt the directory, this is going to involve a symlink swap and >> require a refresh. Does that seem fair enough? Currently I am blocked >> on this extension without a way to make it usable as it requires >> manually hitting F5 each time. > > There has been some work done on symlink monitoring but eventually we > found out it is too expensive and never committed the code upstream. > > http://bugzilla.gnome.org/show_bug.cgi?id=536172 > http://bugzilla.gnome.org/show_bug.cgi?id=546954 >
Interesting, this sounds cool. I am surprised however that in the case of 546954 using inotify is too expensive. I would have thought the only expense is handling the signal and refreshing the view and there wouldn't be an overhead when symlinks aren't being modified. Is this not true? Perhaps I don't understand inotify fully. Either way it is great to know of this patch, if it still applies I can at least have a custom version to throw in a PPA with my extension and have it be functional. -- Michael Rooney mroo...@gmail.com -- nautilus-list mailing list nautilus-list@gnome.org http://mail.gnome.org/mailman/listinfo/nautilus-list