Commit Graph

84 Commits

Author SHA1 Message Date
Marco Trevisan (Treviño)
fe38a02c62 gmodule: Define a gmodule include dependency and use it in gio modules
Various gio modules include gmodule.h that requires the
gmodule-visibility.h to be already built.

To make this easier, just provide a dependency and use it where we are
building modules that do not depend on libgio_dep (that already includes
that).

Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2982
2023-04-19 21:10:29 +02:00
Philip Withnall
56c013cb6e inotify: Use IN_NONBLOCK to avoid a fcntl() syscall where possible
The `inotify_init1()` API has supported this flag for a long time
(possibly since it was first introduced, although I haven’t bothered
doing the archaeology).

This saves a syscall when first connecting to inotify.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2023-03-23 14:11:36 +00:00
Philip Withnall
9d7c796f1e Merge branch 'fix-monitor-root-directory-fail' into 'main'
inotify: Avoid empty root directory string

See merge request GNOME/glib!3241
2023-03-16 12:12:01 +00:00
Eli Schwartz
740440774a
fix underspecified dependencies on generated headers
Since gmodule-visibility.h is now a custom target and produced at
buildtime, it might not always exist in time for use in other source
files. This was the case for gio-inotify.

Add it as an additional source file to ensure in-time generation.
2023-02-06 23:00:04 -05:00
wangrong
2643961845 inotify: Avoid empty root directory string
When gio monitors a directory, it will delete the extra "/" at the end
of the directory string, but when the directory is "/", this will cause
the modified directory string to be empty, and eventually the
monitoring will fail. The solution is to delete only if the directory
string length is greater than 1.
2023-02-03 08:38:51 +00:00
Simon McVittie
c1ee1a99bc gio: Use hidden symbol visibility in static libraries
Building GLib 2.75.0 on Linux adds various inotify-related internal
symbols to the ABI, which doesn't seem to have been intentional.
I went through the other libraries in the build system, and it looks
as though the BSD kqueue backend would have the same problem.

GNU symbol visibility probably doesn't do anything for gio/win32, but
for completeness I've set that to use hidden symbols too, on the basis
that it'll be easier to get this right if we're consistent.

Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2811
Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-11-14 12:36:22 +00:00
Xavier Claessens
8733d172a3 Do not define GIO_COMPILATION for executables
It must only be defined when building libgio. This requires some
workaround to allow include of some gio private headers.

When GIO_COMPILATION is not defined we cannot include individual gio
headers. We workaround that by defining __GIO_GIO_H_INSIDE__ in some
places. Also gdbusprivate.h is not an installed header, so it's fine to
include it directly.
2022-10-13 20:53:56 -04:00
Philip Withnall
8e963e0e31 Port internal uses to use g_source_set_static_name()
This should reduce allocations.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2021-07-26 11:01:07 +01:00
Gaël Bonithon
df500c68a4 inotify: Fix a memory leak
Fixes: #2311
2021-06-03 19:04:48 +02:00
Emmanuel Fleury
3b02d4641e Fix missing initializer warning in gio/inotify/inotify-kernel.c:ik_source_new()
gio/inotify/inotify-kernel.c: In function ‘ik_source_new’:
gio/inotify/inotify-kernel.c:377:3: error: missing initializer for field ‘finalize’ of ‘GSourceFuncs’ {aka ‘struct _GSourceFuncs’}
  377 |   };
      |   ^
In file included from glib/giochannel.h:33,
                 from glib/glib.h:54,
                 from gio/inotify/inotify-kernel.c:30:
glib/gmain.h:272:14: note: ‘finalize’ declared here
  272 |   void     (*finalize) (GSource    *source); /* Can be NULL */
      |              ^~~~~~~~
2020-12-16 23:26:34 +01:00
Philip Withnall
e257e17d2e inotify: Fix some enum comparisons to integers
`-1` isn’t a valid member of the enum, so cast to `int` first. This
fixes a compiler warning on Android.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-10-08 13:49:40 +01:00
Дилян Палаузов
512655aa12 minor typos in the documentation (a/an) 2019-08-24 19:14:05 +00:00
Philip Withnall
fa5996927f Merge branch 'drop-g-disable-deprecated' into 'master'
Drop G_DISABLE_DEPRECATED

Closes #1060 and #638

See merge request GNOME/glib!871
2019-06-14 11:24:25 +00:00
Maya Rashish
de2ad60578 Include <sys/filio.h> for FIONREAD 2019-06-04 13:13:37 +03:00
Philip Withnall
1741fc2c6e build: Drop use of G_DISABLE_DEPRECATED from the build system
It’s no longer used in any of the headers. See preceding commits.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-05-30 10:38:45 +01:00
Philip Withnall
1b50643c99 gio: Fix various compiler warnings when compiling with G_DISABLE_ASSERT
Mostly unused variables which are only used in a g_assert() call
otherwise.

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

Helps: #1708
2019-03-08 19:46:21 +00:00
Philip Withnall
b3efef5b6f build: Drop autotools support
So long, and thanks for everything. We’re a Meson-only shop now.

glib-2-58 will remain the last stable GLib release series which is
buildable using autotools.

We continue to install autoconf macros for autotools-using projects
which depend on GLib; they are stable API.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-01-15 15:11:43 +00:00
Philip Withnall
9d6a69b73e gio: Link inotify file monitor to GLib and GObject
Apparently this is needed for building PE libraries. It makes no
difference on Linux, where linking of the GLib symbols in the inotify
file monitor code is done lazily.

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

https://gitlab.gnome.org/GNOME/glib/issues/1201
2018-07-09 10:38:04 +01:00
Philip Withnall
3e4e005c96 inotify: Further fixes for hard link monitoring support
This gets the G_FILE_MONITOR_WATCH_HARD_LINKS flag to the state where it
doesn’t cause crashes, and essentially acts as a no-op. It will not yet
actually monitor for changes made via hard links.

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

https://bugzilla.gnome.org/show_bug.cgi?id=755721
2018-04-18 15:13:02 +01:00
Ryan Lortie
cc5cd5e8ea inotify: fix segfault on watching hard links
The call to _start() fills in the dirname, basename, and filename
arguments according to the following rules:

  dir watches: dirname filled

  file watches: dirname and basename filled

  hardlink: filename filled

This doesn't map to how the current inotify backend works very nicely,
so we need to adjust things a bit when creating our "sub" objects.

https://bugzilla.gnome.org/show_bug.cgi?id=755721
2018-04-18 15:09:44 +01:00
Emmanuele Bassi
dd8d33d968 Initialize boolean variable
There can be branches where the `interesting` variable isn't
initialized.

https://bugzilla.gnome.org/show_bug.cgi?id=794732
2018-03-28 11:49:59 +01:00
Ernestas Kulik
03e86d000f Remove HAVE_CONFIG_H defs and uses
Since GLib files are only meant to be built as part of GLib, config.h
always exists, so the checks are more or less pointless.

https://bugzilla.gnome.org/show_bug.cgi?id=793399
2018-02-21 13:57:10 +00:00
Philip Withnall
2a0db6d868 inotify: Add missing commas
These were accidentally omitted from commit
748bb24985. My fault.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2017-11-28 14:25:34 +00:00
Philip Withnall
748bb24985 inotify: Don’t propagate unrecognised events to GLocalFileMonitor
If we can’t convert the inotify event mask into a GFileMonitorEvent enum
value, don’t propagate it to GLocalFileMonitor, since it hits an
assertion failure in that case.

This should no longer be possible since the previous commit to ignore
IN_Q_OVERFLOW events, but we might as well change this just in case
other bugs crop up in event mask handling.

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
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
Philip Withnall
5cddde1fb2 Consistently save errno immediately after the operation setting it
Prevent the situation where errno is set by function A, then function B
is called (which is typically _(), but could be anything else) and it
overwrites errno, then errno is checked by the caller.

errno is a horrific API, and we need to be careful to save its value as
soon as a function call (which might set it) returns. i.e. Follow the
pattern:
  int errsv, ret;
  ret = some_call_which_might_set_errno ();
  errsv = errno;

  if (ret < 0)
    puts (strerror (errsv));

This patch implements that pattern throughout GLib. There might be a few
places in the test code which still use errno directly. They should be
ported as necessary. It doesn’t modify all the call sites like this:
  if (some_call_which_might_set_errno () && errno == ESOMETHING)
since the refactoring involved is probably more harmful than beneficial
there. It does, however, refactor other call sites regardless of whether
they were originally buggy.

https://bugzilla.gnome.org/show_bug.cgi?id=785577
2017-08-03 10:21:13 +01:00
Patrick Griffis
d10be6102f meson: Minor modernizations 2017-07-13 19:03:39 -04:00
Nirbheek Chauhan
fe2a9887a8 meson: Improve MSVC and MinGW support and fix dependencies everywhere
Disable gio tests on Windows, fix .gitignore to not ignore
config.h.meson, and add more things to it.

Rename the library file naming and versioning to match what Autotools
outputs, e.g., libglib-2.0.so.0.5000.2 on Linux, libglib-2.0-0.dll  and
glib-2.0-0.dll on Windows with MSVC.

Several more tiny fixes, more executables built and installed, install
pkg-config and m4 files, fix building of gobject tests.

Changes to gdbus-codegen to support out-of-tree builds without
environment variables set (which you can't in Meson). We now add the
build directory to the Python module search path.
2017-07-13 19:03:39 -04:00
Tim-Philipp Müller
213957970e meson: Fix glib, add gobject, gio, gthread, gmodule, etc
Several small fixes to the build files.

Lots of tests have also been added, and glib tests pass now.
2017-07-13 19:03:39 -04: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
b995c08bf3 Remove unused files
We no longer have GLocalDirectoryMonitor implementations.
These files were not included in the build for a while now.
2015-08-20 22:31:41 -04: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
fd40b5942d inotify: fix move event matching accounting
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
2015-03-26 14:56:25 -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
3d2d4b8efe inotify: send CHANGES_DONE when new files 'appear'
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.
2015-03-20 12:01:34 -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
Ryan Lortie
779c809a3d inotify: rewrite inotify-kernel
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
2015-03-20 11:58:42 -04:00
William Jon McCann
20f4d1820b docs: use "Returns:" consistently
Instead of "Return value:".
2014-02-19 19:41:52 -05:00
Ryan Lortie
450e7b1036 configure.ac: tweak inotify check
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
2014-02-14 10:42:40 -05:00
Daniel Mustieles
078dbda148 Updated FSF's address 2014-01-31 14:31:55 +01:00
Ryan Lortie
700677de51 inotify: stop using constructor()
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
2013-10-03 10:37:30 -04:00
Matthias Clasen
3bdd8a2c88 Use GLIB_PRIVATE_CALL macro
I accidentally pushed the fix for bug 704873 before
applying this cleanup.
2013-07-28 18:44:41 -04:00
Ryan Lortie
abbb225738 inotify: don't assume mainloop is running
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
2013-07-28 17:19:38 -04:00
Matthias Clasen
e546eb016a Remove some unused inotify code 2013-06-02 20:01:56 -04:00
Ryan Lortie
f9eb9eed10 Rework the build system for a new tests approach
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.
2013-05-31 23:12:15 -04: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
52a81a7d86 Remove a few more G_GNUC_INTERNAL users 2013-01-18 13:28:43 -05:00
Ryan Lortie
346aa683de Fix visibility for glib/ and gio/ submodules
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.
2013-01-18 13:23:40 -05:00