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.
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
The hash table stores the list of unmatched IN_MOVE_FROM events, but we
were removing entries from it when popping IN_MOVE_TO events.
Fix that up to correct a crash in nautilus due to the assertion failure
below.
https://bugzilla.gnome.org/show_bug.cgi?id=746749
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).
We generally assume that an IN_CREATE event is the start of a series of
events in which another process is doing this:
fd = creat (...) -> IN_CREATE
write (fd, ..) -> IN_MODIFY
write (fd, ..) -> IN_MODIFY
close (fd) -> IN_CLOSE_WRITE
and as such, we use the CHANGES_DONE_HINT event after CREATED in order
to show when this sequence of events has completed (ie: when we receive
IN_CLOSE_WRITE when the user closes the file).
Renaming a file into place is handled by IN_MOVED_FROM so we don't have
to worry about that.
There are many other cases, however, where a new file 'appears' in a
directory in its completed form already, and the kernel reports
IN_CREATE. Examples include mkdir, mknod, and the creation of
hardlinks. In these cases, there is no corresponding IN_CLOSE_WRITE
event and the CHANGES_DONE_HINT will have to be emitted by an arbitrary
timeout.
Try to detect some of these cases and report CHANGES_DONE_HINT
immediately.
This is not perfect. There are some cases that will not be reliably
detected. An example is if the user makes a hardlink and then
immediately deletes the original (before we can stat the new file).
Another example is if the user creates a file with O_TMPFILE. In both
of these cases, CHANGES_DONE_HINT will still eventually be delivered via
the timeout.
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.
Remove the hardwired 1 second event queue logic from inotify-kernel and
replace it with something vastly less complicated.
Events are now reported as soon as is possible instead of after a
delay.
We still must delay IN_MOVED_FROM events in order to look for the
matching IN_MOVED_TO events, and since we want to report events in order
this means that events behind those events can also be delayed. We
limit ourselves, however:
- no more than 100 events can be delayed at a time
- no event can be delayed by more than 10ms
https://bugzilla.gnome.org/show_bug.cgi?id=627285
Our check for inotify_init1() being defined is broken. We happily
declare that inotify is supported, even if the check fails.
This was originally intended to check for inotify_init1 in the libc so
that we could fall back to inotify_init if it was not yet defined.
FreeBSD has a libinotify that emulates the inotify API via kqueue. It
installs a <sys/inotify.h> header and requires linking to -linotify. We
don't want to falsely detect working inotify in this case.
Treat the lack of inotify_init1() in the libc as a lack of inotify
support. This requires only a new libc -- we still support old kernels:
in the case that inotify1_init() fails, we fall back to inotify_init().
https://bugzilla.gnome.org/show_bug.cgi?id=724330
and start using the new start() vcall on the local monitor classes.
I only port inotify because I am uncomfortable making changes to the
other monitor backends without having a way of testing them.
https://bugzilla.gnome.org/show_bug.cgi?id=704887
GFileMonitor takes great care to sample the thread-default main context
at the time that it is created in order that events can be dispatched to
the correct thread when they come in.
The inotify GFileMonitor implementation uses a global file descriptor
shared between all watches. It has to poll this file descriptor from
somewhere so it arbitrarily picks the default main context.
The problem with that is that the user might not be running it.
Let's use the GLib worker thread for this instead. It's guaranteed to
be running if you need it, and this is exactly the sort of problem it
was meant to solve.
https://bugzilla.gnome.org/show_bug.cgi?id=704873
Perform a substantial cleanup of the build system with respect to
building and installing testcases.
First, Makefile.decl has been renamed glib.mk and substantially
expanded. We intend to add more stuff here in the future, like canned
rules for mkenums, marshallers, resources, etc.
By default, tests are no longer compiled as part of 'make'. They will
be built when 'make check' is run. The old behaviour can be obtained
with --enable-always-build-tests.
--disable-modular-tests is gone (because tests are no longer built by
default). There is no longer any way to cause 'make check' to be a
no-op, but that's not very useful anyway.
A new glibtests.m4 file is introduced. Along with glib.mk, this
provides for consistent handling of --enable-installed-tests and
--enable-always-build-tests (mentioned above).
Port our various test-installing Makefiles to the new framework.
This patch substantially improves the situation in the toplevel tests/
directory. Things are now somewhat under control there. There were
some tests being built that weren't even being run and we run those now.
The long-running GObject performance tests in this directory have been
removed from 'make check' because they take too long.
As an experiment, 'make check' now runs the testcases on win32 builds,
by default. We can't run them under gtester (since it uses a pipe to
communicate with the subprocess) so just toss them in TESTS. Most of
them are passing on win32.
Things are not quite done here, but this patch is already a substantial
improvement. More to come.
We have various sub directories in glib/ and gio/ (eg: inotify, gnulib,
pcre, xdgmime, etc.) that build convenience libraries that are then
included into libglib and libgio. The files in these directories need
to be built with the same visibility policy as the files in the first
level directories, so add CFLAGS for them all.
This wasn't a problem when the visibility flags were set directly in
CFLAGS but then we had to deal with some modules that we built that we
explicitly wanted to export symbols from.
For now, we can keep things the way they are because it's less hacky and
although it's a theoretical hazard to forget these CFLAGS, we rarely add
new subdirectories to the build.
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
This patch makes GFileMonitor to emit EVENT_CHANGES_DONE_HINT when
EVENT_CREATED is emitted but the file is not opened for writing.
On file moves across different mounted volumes, inotify will always emit
IN_CREATE and IN_CLOSE_WRITE (plus other events).
This translates into GIO's _EVENT_CREATED and _EVENT_CHANGES_DONE_HINT.
On file moves across the same mounted volumes, inotify will emit
IN_MOVED_FROM/IN_MOVED_TO which will be translated into
_EVENT_DELETED/_EVENT_CREATED GIO's side. No _EVENT_CHANGES_DONE_HINT is
emited afterwards.
Under such circumstances a file indexer does not know when actually the
file is ready to be indexed, either waiting too much or triggering the
indexing twice. On small devices it's not advisable.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=640077
Bug-NB: NB#219982
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Tomas Bzatek <tbzatek@redhat.com>
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>.
2008-07-01 Cody Russell <bratsche@gnome.org>
* gio/gioenums.h:
* gio/giotypes.h:
Moved all relevant typedefs into these files.
* gio/*.[ch]:
Updated wrt added files.
Split types into separate file for easier maintainership. (#538564)
svn path=/trunk/; revision=7127
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-07 Alexander Larsson <alexl@redhat.com>
* Makefile.am:
Build test subdir after .
Remove gdirectorymonitor.[ch]
* gdirectorymonitor.[ch]:
* gfilemonitor.c:
* gfile.[ch]:
* gio.h:
Remove GDirectoryMonitor and make
GFileMonitor the baseclass for both file and
directory monitors. Lift the more generic
rate limiting code from GDirectoryMonitor
into GFileMonitor.
* fam/fam-helper.c:
* fam/gfamdirectorymonitor.[ch]:
* inotify/ginotifydirectorymonitor.[ch]:
* inotify/inotify-helper.c:
* glocaldirectorymonitor.[ch]:
* glocalfile.c:
* gvolumemonitor.c:
Update for the removed GDirectoryMonitor.
* gmemoryoutputstream.c:
Remove ununsed variable
svn path=/trunk/; revision=6262
