Commit Graph

15 Commits

Author SHA1 Message Date
Philip Withnall
9853842c53 inotify: Ignore IN_Q_OVERFLOW events
There’s not much we can do about them, and if they go unhandled, they
can propagate through to g_file_monitor_source_handle_event() and cause
assertion failures due to not mapping to a GFileMonitorEvent.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

https://bugzilla.gnome.org/show_bug.cgi?id=776147
2017-11-28 13:55:34 +00:00
Sébastien Wilmet
6000f25e4f gio/inotify/: LGPLv2+ -> LGPLv2.1+
https://bugzilla.gnome.org/show_bug.cgi?id=776504
2017-05-29 19:53:34 +02:00
Sébastien Wilmet
f60590534d License headers: "the Gnome Library" -> "this library"
Harmonize a little the license headers. In most of the license headers
in GLib, it is "this library".

It is also what is explained at:
https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html#SEC4
"How to Apply These Terms to Your New Libraries"

https://bugzilla.gnome.org/show_bug.cgi?id=776586
2017-01-04 19:12:56 +01:00
Matthias Clasen
d66e3f57cd Add more directory monitoring tests
These tests clear up a misunderstanding of mine: Monitoring
nonexisting files and directories *does* work with the inotify
implementation, it just has a very long timeout for scanning
for missing locations, so the test needs to take that into
account.
2015-08-20 22:30:19 -04:00
Matthias Clasen
ac78d14125 inotify: Fix handling of paired events for atomic replace
After the big file monitoring rewrite, we only put the IN_MOVED_FROM event
in the queue for such pairs. It matches INOTIFY_DIR_MASK and thus we call
ip_dispatch_event on it, but that function was filtering it out because
the filename in the 'from' event is the one of the temp file, not the
one we are monitoring. That name is in the 'to' event, so compare it as
well, and let the event passin that case.

There is another instance of this check in glocalfilemonitor.c, which is
corrected here as well.

https://bugzilla.gnome.org/show_bug.cgi?id=751358
2015-08-19 14:57:53 -04:00
Ryan Lortie
c5d5e2916b inotify: implement "boredom" algorithm
Use the "interesting" value from g_file_monitor_source_handle_event() to
decide if we're currently being flooded by a stream of boring events.

The main case here is when one or more files is being written to and the
change events are all being rate-limited in the GFileMonitor frontends.

In that case, we become "bored" with the event stream and add a backoff
timeout.  In the case that it is exactly one large file being written
(which is the common case) then leaving the event in the queue also lets
the kernel perform merging on it, so when we wake up, we will only see
the one event.  Even in the case that the kernel is unable to perform
merging, the context switch overhead will be vastly reduced.

In testing, this cuts down on the number of wake ups during a large file
copy, by a couple orders of magnitude (ie: less than 1% of the number of
wake ups).
2015-03-20 12:01:35 -04:00
Ryan Lortie
2737ab3201 substantially rework file monitors
Remove all event merging and dispatch logic from GFileMonitor.  The only
implementation of GFileMonitor outside of glib is in gvfs and it already
does these things properly.

Get rid of GLocalDirectoryMonitor.  We will use a single class,
GLocalFileMonitor, for both directory and file monitoring.  This will
prevent every single backend from having to create two objects
separately (eg: ginotifydirectorymonitor.c and ginotifyfilemonitor.c).

Introduce GFileMonitorSource as a thread-safe cross-context dispatch
mechanism.  Put it in GLocalFileMonitor.  All backends will be expected
to dispatch via the source and not touch the GFileMonitor object at all
from the worker thread.

Remove all construct properties from GLocalFileMonitor and remove the
"context" construct property from GFileMonitor.  All backends must now
get the information about what file to monitor from the ->start() call
which is mandatory to implement.

Remove the implementation of rate limiting in GFileMonitor and add an
implementation in GLocalFileMonitor.  gvfs never did anything with this
anyway, but if it wanted to, it would have to implement it for itself.
This was done in order to get the rate_limit field into the
GFileMonitorSource so that it could be safely accessed from the worker
thread.

Expose g_local_file_is_remote() internally for NFS detection.

With the "is_remote" functionality exposed, we can now move all
functions for creating local file monitors to a proper location in
glocalfilemonitor.c

Port the inotify backend to adjust to the changes above.  None of the
other backends are ported yet.  Those will come in future commits.
2015-03-20 11:59:47 -04:00
Daniel Mustieles
078dbda148 Updated FSF's address 2014-01-31 14:31:55 +01:00
Cosimo Cecchi
40f8e15c1b inotify: fix a memleak
https://bugzilla.gnome.org/show_bug.cgi?id=692201
2013-01-21 09:51:09 -05:00
Ryan Lortie
707bc4a40f gio + inotify support for hard links
Add a new GFileMonitorFlag: G_FILE_MONITOR_WATCH_HARD_LINKS.  When set,
changes made to the file via another hard link will be detected.

Implement the new flag for the inotify backend.

https://bugzilla.gnome.org/show_bug.cgi?id=532815
2012-12-19 08:19:18 -05:00
Christian Kellner
48f74cab39 Move event support in the inotify backend
This adds support for G_FILE_MONITOR_SEND_MOVED events when requested by
the user to the inotify backend. Last part to fix bug #547890.
Based heavily on a patch by Martyn Russel <martyn@lanedo.com>.
2010-02-18 15:50:26 +01:00
Alexander Larsson
ab7e80d366 Define IN_ONLYDIR if not in header (#515346)
2008-02-13  Alexander Larsson  <alexl@redhat.com>

	* inotify/inotify-path.c:
	Define IN_ONLYDIR if not in header (#515346)



svn path=/trunk/; revision=6510
2008-02-13 13:33:57 +00:00
Alexander Larsson
d8473705b0 Removed. Removed. Removed the included copies of the inotify headers. We
2008-01-21  Alexander Larsson  <alexl@redhat.com>

        * inotify/Makefile.am:
        * inotify/inotify-helper.c:
        * inotify/inotify-kernel.c:
        * inotify/inotify-path.c:
        * inotify/local_inotify.h: Removed.
        * inotify/local_inotify_syscalls.h: Removed.
	Removed the included copies of the inotify
	headers. We now only use the <sys/inotify.h>
	header which exists on modern systems.
	This fixes problems on ARM and SH5 (#510448)
	but is also generally much cleaner and future
	safe. For instance, if other OSes add support
	for inotify it should "just work".



svn path=/trunk/; revision=6338
2008-01-21 10:35:44 +00:00
Matthias Clasen
a043325ec1 Coding style fixes
svn path=/trunk/; revision=6337
2008-01-21 05:12:16 +00:00
Alexander Larsson
3781343738 gio/ docs/reference/gio Merged gio-standalone into glib.
2007-11-26  Alexander Larsson  <alexl@redhat.com>

        * Makefile.am:
        * configure.in:
        * gio-2.0-uninstalled.pc.in:
        * gio-2.0.pc.in: 
        * gio-unix-2.0-uninstalled.pc.in:
        * gio-unix-2.0.pc.in:
	* gio/
	* docs/reference/gio
	Merged gio-standalone into glib.
	
        * glib/glibintl.h:
        * glib/gutils.c:
	Export glib_gettext so that gio can use it
	Add P_ (using same domain for now)
	Add I_ as g_intern_static_string


svn path=/trunk/; revision=5941
2007-11-26 16:13:05 +00:00