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

Reply via email to