After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 546954 - Nautilus symlink monitoring support
Nautilus symlink monitoring support
Status: RESOLVED OBSOLETE
Product: nautilus
Classification: Core
Component: general
2.23.x
Other Linux
: Normal enhancement
: ---
Assigned To: Tomas Bzatek
Nautilus Maintainers
: 701938 (view as bug list)
Depends on: 536172
Blocks: 604912
 
 
Reported: 2008-08-08 15:25 UTC by Tomas Bzatek
Modified: 2021-06-18 15:55 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
nautilus-inotify-symlink-support.patch (5.38 KB, patch)
2008-08-08 15:27 UTC, Tomas Bzatek
none Details | Review
rebased patch (6.13 KB, patch)
2014-10-01 14:49 UTC, David King
needs-work Details | Review

Description Tomas Bzatek 2008-08-08 15:25:25 UTC
This patch is supplement to the GIO inotify symlink support introduced in bug 536172. It allows Nautilus to monitor symlinks and update UI accordingly. Changes in symlink destination are reflected immediately, including type changes from file to directory and vice versa.

For this to work, I had to add new monitor type and also add support to list view mode for directory <--> file mutation. Each symlink monitor (pointing to a file) will eat one inotify slot, however the real slots used will be much lower since we're always monitoring parent directory to detect file changes and GFileMonitor manages internal watch lists to avoid duplication.

Live changes of number of items in subdirectories (in detailed list view) are still not supported anyway; we discussed this with upstream developers and concluded it's too expensive for inotify slots (whose number is quite limited).
Comment 1 Tomas Bzatek 2008-08-08 15:27:18 UTC
Created attachment 116156 [details] [review]
nautilus-inotify-symlink-support.patch

Patch against trunk
Comment 2 Christian Neumair 2008-08-10 11:35:02 UTC
Thanks for your efforts!

Does this really need support at GIO level? Nautilus has a symbolic link hash table (nautilus-file.c:symbolic_links). Wouldn't it be more simple to map NautilusFile changes using this table?
Comment 3 Tomas Bzatek 2008-08-12 09:22:34 UTC
The GIO inotify symlink support is quite complex and I don't want to duplicate efforts. Now that nautilus is dependent on new glib, I think we can rely on it. With older versions of glib2 (2.16 series) it should compile without error, it just won't be working.
Comment 4 Cosimo Cecchi 2012-07-20 16:06:54 UTC
Mass component change due to BZ cleanup, sorry for the noise.
Comment 5 David King 2014-10-01 14:49:13 UTC
Created attachment 287521 [details] [review]
rebased patch

I rebased the patch against current master, as I missed the bit of the first comment mentioning that resolving bug 536172 is a prerequisite.
Comment 6 António Fernandes 2020-02-08 21:22:05 UTC
*** Bug 701938 has been marked as a duplicate of this bug. ***
Comment 7 André Klapper 2021-06-18 15:55:45 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org (resources are unfortunately quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of Files (nautilus), then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/nautilus/-/issues/

Thank you for your understanding and your help.