GLib issueshttps://gitlab.gnome.org/GNOME/glib/-/issues2024-02-09T19:32:37Zhttps://gitlab.gnome.org/GNOME/glib/-/issues/3241Use after free in GWin32FileMonitor2024-02-09T19:32:37ZgwillemsUse after free in GWin32FileMonitorOn Win32 platform, when a `GFileMonitor` gets cancelled with `g_file_monitor_cancel()`, the underlying HANDLE object `monitor->hDirectory` gets [closed](https://gitlab.gnome.org/GNOME/glib/-/blob/glib-2-78/gio/win32/gwin32fsmonitorutils....On Win32 platform, when a `GFileMonitor` gets cancelled with `g_file_monitor_cancel()`, the underlying HANDLE object `monitor->hDirectory` gets [closed](https://gitlab.gnome.org/GNOME/glib/-/blob/glib-2-78/gio/win32/gwin32fsmonitorutils.c?ref_type=heads#L415), then the OS will notify us through `g_win32_fs_monitor_callback()`, which [checks the cancelled flag](https://gitlab.gnome.org/GNOME/glib/-/blob/glib-2-78/gio/win32/gwin32fsmonitorutils.c?ref_type=heads#L139) and, if set, will [free](https://gitlab.gnome.org/GNOME/glib/-/blob/glib-2-78/gio/win32/gwin32fsmonitorutils.c?ref_type=heads#L143) the `GWin32FSMonitorPrivate` instance, even before it's disposed!
In case `g_win32_fs_monitor_finalize` gets called afterwards, it will try to free again the GWin32FSMonitorPrivate instance members, and will crash if it has been overwritten on the heap since the previous free from the callback.
Typical reproducer: in Python, the disposal/finalization is done at garbage collection, which can happen a long time after the cancellation callback was processed, letting enough time to corrupt the heap where the GFileMonitor was allocated.
## Typical "good" trace
When the GFileMonitor gets freed immediately after the "cancel" (typically how it happens in C code), we observe this kind of trace:
```
--- User calls g_free(my_gfilemonitor)
GLocalFileMonitor dispose
GFileMonitorSource dispose
GFileMonitor dispose
GWin32FileMonitor finalize
GWin32FSMonitorPrivate finalize
\_ sets monitor->self = NULL
GLocalFileMonitor finalize
GFileMonitorSource finalize
...
--- Win32 notifies CloseHandle result
g_win32_fs_monitor_callback
\_ if (monitor->self == NULL) g_free (monitor);
```
## Typical "bad" trace
When the GFileMonitor gets freed late after the "cancel" (typically a late garbage collection from Python), we observe this kind of trace:
```
--- Win32 notifies CloseHandle result
g_win32_fs_monitor_callback
\_ if (g_file_monitor_is_cancelled (monitor->self)) g_free (monitor);
...
(app running, something overwrites the heap)
...
--- python gc.collect()
GLocalFileMonitor dispose
GFileMonitorSource dispose
GFileMonitor dispose
GWin32FileMonitor finalize
GWin32FSMonitorPrivate finalize
\_ g_free (monitor->wfullpath_with_long_prefix); --> pointer address corrupted --> BOOM!!!
```
## Backtrace
Crash (use-after-free), when `g_win32_fs_monitor_finalize` tries to free the file paths:
[filemonitor_crash.txt](/uploads/81d712074b28b0d447bee688aaf9686d/filemonitor_crash.txt)
## Additional information
Observed on Windows10 + msys2, official package mingw-w64-ucrt-x86_64-glib2 2.78.4-2
Debugged on today's git commit d8e4f39a, self-compiled.https://gitlab.gnome.org/GNOME/glib/-/issues/2624Use fanotify to monitor directory hierarchies2023-07-09T16:15:05ZBastien NoceraUse fanotify to monitor directory hierarchiesI learnt through tracker's NEWS file that [fanotify now supports queries by normal users](https://gitlab.gnome.org/GNOME/tracker-miners/-/commits/master/src/libtracker-miner/tracker-monitor-fanotify.c)
We could extend `GFileMonitorFlags...I learnt through tracker's NEWS file that [fanotify now supports queries by normal users](https://gitlab.gnome.org/GNOME/tracker-miners/-/commits/master/src/libtracker-miner/tracker-monitor-fanotify.c)
We could extend `GFileMonitorFlags` to allow monitoring directory trees.
CC @carlosghttps://gitlab.gnome.org/GNOME/glib/-/issues/2587File monitor doesn’t emit unmount signal when monitoring a file path2022-01-28T01:18:08Zlan xsFile monitor doesn’t emit unmount signal when monitoring a file pathI monitor u disk file, when I unmount u disk, no signal received。
but monitor u disk directory, it works fineI monitor u disk file, when I unmount u disk, no signal received。
but monitor u disk directory, it works finehttps://gitlab.gnome.org/GNOME/glib/-/issues/1634testfilemonitor failure in CI: assertion failed (e1->step == e2->step): (-1 =...2023-03-03T11:40:29ZSimon McVittietestfilemonitor failure in CI: assertion failed (e1->step == e2->step): (-1 == 2)https://gitlab.gnome.org/smcv/glib/-/jobs/179824 (testing an unrelated MR):
```
158/260 glib:gio+slow / testfilemonitor FAIL 2.30 s (killed by signal 6 SIGABRT)
--- command ---
GIO_MODULE_DIR='' GIO_LAUNCH_DESKTOP='/builds/...https://gitlab.gnome.org/smcv/glib/-/jobs/179824 (testing an unrelated MR):
```
158/260 glib:gio+slow / testfilemonitor FAIL 2.30 s (killed by signal 6 SIGABRT)
--- command ---
GIO_MODULE_DIR='' GIO_LAUNCH_DESKTOP='/builds/smcv/glib/_build/gio/gio-launch-desktop' G_TEST_SRCDIR='/builds/smcv/glib/gio/tests' G_TEST_BUILDDIR='/builds/smcv/glib/_build/gio/tests' /builds/smcv/glib/_build/gio/tests/testfilemonitor --tap
--- stdout ---
# random seed: R02S813f73c37d8f0911ed7753ae17ebeef2
1..6
# Start of monitor tests
Bail out! GLib-GIO:ERROR:../gio/tests/testfilemonitor.c:216:check_expected_events: assertion failed (e1->step == e2->step): (-1 == 2)
--- stderr ---
**
GLib-GIO:ERROR:../gio/tests/testfilemonitor.c:216:check_expected_events: assertion failed (e1->step == e2->step): (-1 == 2)
-------
```
It succeeded (but a different test failed) when I retried CI.https://gitlab.gnome.org/GNOME/glib/-/issues/1370_ip_get_path_for_wd assertion failed: (wd >= 0)2019-09-26T15:38:51ZBugzilla_ip_get_path_for_wd assertion failed: (wd >= 0)## Submitted by Marco Trevisan `@3v1n0`
**[Link to original bug (#795522)](https://bugzilla.gnome.org/show_bug.cgi?id=795522)**
## Description
In Ubuntu we're getting some reports about this crash (see https://errors.ubuntu.com/prob...## Submitted by Marco Trevisan `@3v1n0`
**[Link to original bug (#795522)](https://bugzilla.gnome.org/show_bug.cgi?id=795522)**
## Description
In Ubuntu we're getting some reports about this crash (see https://errors.ubuntu.com/problem/7d4e9fc521926903d3f796d9d01b38c242396745, you might get access from https://forms.canonical.com/reports/)
```
#0 raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:51
set = {__val = {18446744067266838239, 538, 539, 540, 541, 542, 543, 544, 545, 546, 547, 548, 549, 550, 551, 552}}
pid = <optimized out>
tid = <optimized out>
#1 0x0000561a5bb82a8b in dump_gjs_stack_on_signal_handler (signo=6) at ../src/main.c:372
sa = {__sigaction_handler = {sa_handler = 0x561a5bb82ac0 <dump_gjs_stack_alarm_sigaction>, sa_sigaction = 0x561a5bb82ac0 <dump_gjs_stack_alarm_sigaction>}, sa_mask = {__val = {0 <repeats 16 times>}}, sa_flags = 0, sa_restorer = 0x0}
i = 65
#2 <signal handler called>
No locals.
#3 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
set = {__val = {18446744067266838239, 139951509340162, 0, 6, 32, 24, 32, 7875667050066240512, 0, 139952381755424, 2064, 139952381755424, 2048, 139952381762944, 0, 139952854851350}}
pid = <optimized out>
tid = <optimized out>
#4 0x00007f49502daf5d in __GI_abort () at abort.c:90
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = {__val = {7875667050066240512, 94669669138432, 139952381762944, 110, 139952892173536, 139952492541904, 139952895968160, 0, 139952854864894, 139952381762944, 0, 0, 7875667050066240512, 139952895968064, 7875667050066240512, 139952895764312}}, sa_flags = 872422784, sa_restorer = 0x6e}
sigs = {__val = {32, 0 <repeats 15 times>}}
#5 0x00007f495242481d in g_assertion_message (domain=domain@entry=0x7f4952a32758 "GLib-GIO", file=file@entry=0x7f4952a64340 "../../../../../gio/inotify/inotify-path.c", line=line@entry=583, func=func@entry=0x7f4952a643a0 <__func__.9543> "_ip_get_path_for_wd", message=message@entry=0x561a5d16abb0 "assertion failed: (wd >= 0)") at ../../../../glib/gtestutils.c:2436
lstr = "583\000I\177\000\000\000drxt\375Km\300\315\032]\032V\000\000zA\246RI\177\000"
s = 0x7f4934001d80 ""
#6 0x00007f49524248aa in g_assertion_message_expr (domain=domain@entry=0x7f4952a32758 "GLib-GIO", file=file@entry=0x7f4952a64340 "../../../../../gio/inotify/inotify-path.c", line=line@entry=583, func=func@entry=0x7f4952a643a0 <__func__.9543> "_ip_get_path_for_wd", expr=expr@entry=0x7f4952a6417a "wd >= 0") at ../../../../glib/gtestutils.c:2459
s = 0x561a5d16abb0 "assertion failed: (wd >= 0)"
#7 0x00007f4952a2d5d6 in _ip_get_path_for_wd (wd=<optimized out>) at ../../../../../gio/inotify/inotify-path.c:583
dir_list = <optimized out>
dir = <optimized out>
__func__ = "_ip_get_path_for_wd"
#8 0x00007f4952a2d9af in ih_event_callback (event=0x7f4934002b10, sub=0x561a5d214470, file_event=<optimized out>) at ../../../../../gio/inotify/inotify-helper.c:182
parent_dir = <optimized out>
other = <optimized out>
interesting = <optimized out>
__func__ = "ih_event_callback"
#9 0x00007f4952a2ce89 in ip_event_dispatch (dir_list=dir_list@entry=0x561a5ecf9880, file_list=0x0, event=0x7f4934002b10) at ../../../../../gio/inotify/inotify-path.c:492
sub = 0x561a5d214470
subl = 0x561a5ecf9220
dir = 0x561a5fcec590
interesting = 0
l = 0x561a5ecf9880
#10 0x00007f4952a2d062 in ip_event_dispatch (event=<optimized out>, file_list=<optimized out>, dir_list=0x561a5ecf9880) at ../../../../../gio/inotify/inotify-path.c:554
interesting = 0
#11 ip_event_callback (event=event@entry=0x7f4934002b50) at ../../../../../gio/inotify/inotify-path.c:555
event = 0x7f4934002b50
#12 0x00007f4952a2c41a in ik_source_dispatch (source=source@entry=0x561a5cc8fb40, func=0x7f4952a2cfa0 <ip_event_callback>, user_data=<optimized out>) at ../../../../../gio/inotify/inotify-kernel.c:324
event = 0x7f4934002b50
iks = 0x561a5cc8fb40
user_callback = <optimized out>
interesting = 0
now = 930641014
__func__ = "ik_source_dispatch"
#13 0x00007f49523fde25 in g_main_dispatch (context=0x561a5c53ab60) at ../../../../glib/gmain.c:3148
dispatch = 0x7f4952a2c1c0 <ik_source_dispatch>
prev_source = 0x0
was_in_call = 0
user_data = 0x0
callback = 0x7f4952a2cfa0 <ip_event_callback>
cb_funcs = 0x7f49526c5280 <g_source_callback_funcs>
cb_data = 0x561a5cc8fc60
need_destroy = <optimized out>
source = 0x561a5cc8fb40
current = 0x561a5d16e810
i = 0
#14 g_main_context_dispatch (context=context@entry=0x561a5c53ab60) at ../../../../glib/gmain.c:3813
No locals.
#15 0x00007f49523fe1f0 in g_main_context_iterate (context=context@entry=0x561a5c53ab60, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../../../../glib/gmain.c:3886
max_priority = 2147483647
timeout = 10
some_ready = 1
nfds = <optimized out>
allocated_nfds = 2
fds = 0x561a5c5148f0
#16 0x00007f49523fe27c in g_main_context_iteration (context=0x561a5c53ab60, may_block=may_block@entry=1) at ../../../../glib/gmain.c:3947
retval = <optimized out>
#17 0x00007f49523fe2c1 in glib_worker_main (data=<optimized out>) at ../../../../glib/gmain.c:5742
No locals.
#18 0x00007f4952425645 in g_thread_proxy (data=0x561a5c53b800) at ../../../../glib/gthread.c:784
thread = 0x561a5c53b800
#19 0x00007f49506897fc in start_thread (arg=0x7f493a9a9700) at pthread_create.c:465
pd = 0x7f493a9a9700
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139952492549888, 7971392138181629608, 140725622742510, 140725622742511, 139952492549888, 27, -8056262574619470168, -8056180814957226328}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
pagesize_m1 = <optimized out>
sp = <optimized out>
freesize = <optimized out>
__PRETTY_FUNCTION__ = "start_thread"
#20 0x00007f49503b6b0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
```
For some reaseon the parir watch description is unset, not sure if in such case we should just not try to get the path with something like:
diff --git a/gio/inotify/inotify-helper.c b/gio/inotify/inotify-helper.c
index d94458753..a24f1a645 100644
--- a/gio/inotify/inotify-helper.c
+++ b/gio/inotify/inotify-helper.c
@@ -175,7 +175,7 @@ ih_event_callback (ik_event_t *event,
{
GFile *other;
- if (event->pair)
+ if (event->pair && event->pair->wd >= 0)
{
const char *parent_dir;
gchar *fullpath;https://gitlab.gnome.org/GNOME/glib/-/issues/1369Fix missing events when monitoring a file through a hard link in GLocalFileMo...2021-03-10T09:26:24ZBugzillaFix missing events when monitoring a file through a hard link in GLocalFileMonitor## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#795356)](https://bugzilla.gnome.org/show_bug.cgi?id=795356)**
## Description
Following on from bug #755721, we need to investigate and fix the FIXME in `file_har...## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#795356)](https://bugzilla.gnome.org/show_bug.cgi?id=795356)**
## Description
Following on from bug #755721, we need to investigate and fix the FIXME in `file_hard_links_output` in testfilemonitor.c. GLocalFileMonitor is not emitting enough events for file modifications made through a hard link.
If it turns out that inotify doesn’t support this, then it needs to be documented.
Version: 2.56.xhttps://gitlab.gnome.org/GNOME/glib/-/issues/1257Gio.File.monitor_directory can not monitor recursively2018-07-05T10:31:30ZBugzillaGio.File.monitor_directory can not monitor recursively## Submitted by Moo
**[Link to original bug (#781060)](https://bugzilla.gnome.org/show_bug.cgi?id=781060)**
## Description
This is a pain to developers since you have to implement recursion yourself.
I request a monitor_directory_r...## Submitted by Moo
**[Link to original bug (#781060)](https://bugzilla.gnome.org/show_bug.cgi?id=781060)**
## Description
This is a pain to developers since you have to implement recursion yourself.
I request a monitor_directory_recursively method or a parameter that can be passed to indicate that the directory should be monitored recursively.https://gitlab.gnome.org/GNOME/glib/-/issues/1181Test failure: check_expected_events2021-09-23T17:01:48ZBugzillaTest failure: check_expected_events## Submitted by Daniel Macks `@dmacks`
**[Link to original bug (#768550)](https://bugzilla.gnome.org/show_bug.cgi?id=768550)**
## Description
Building glib-2.48.1 on OS X 10.11 with xcode-7.3.1, I get a self-test failure in gio/test...## Submitted by Daniel Macks `@dmacks`
**[Link to original bug (#768550)](https://bugzilla.gnome.org/show_bug.cgi?id=768550)**
## Description
Building glib-2.48.1 on OS X 10.11 with xcode-7.3.1, I get a self-test failure in gio/tests:
ERROR: testfilemonitor - too few tests run (expected 5, got 0)
ERROR: testfilemonitor - exited with status 134 (terminated by signal 6?)
From gio/tests/testfilemonitor.log:
# random seed: R02Sae98c35b286e4a3c94d1fd2e88081d9e
1..5
**
GLib-GIO:ERROR:testfilemonitor.c:93:check_expected_events: assertion failed (n_expected == g_list_length (recorded)): (9 == 10)
# Start of monitor tests
../../tap-test: line 5: 36132 Abort trap: 6 $1 -k --tap
# GLib-GIO:ERROR:testfilemonitor.c:93:check_expected_events: assertion failed (n_expected == g_list_length (recorded)): (9 == 10)
ERROR: testfilemonitor - too few tests run (expected 5, got 0)
ERROR: testfilemonitor - exited with status 134 (terminated by signal 6?)
I know OS X has some filesystem details and interfaces that are different than linux. I'm configuring with --disable-fam, and using older glib I often see console diagnostics about various volume- or directory-monitoring being unavailable.
Version: 2.52.xhttps://gitlab.gnome.org/GNOME/glib/-/issues/1070g_file_monitor should signal error when maximum number of watches has been re...2019-10-11T19:32:25ZBugzillag_file_monitor should signal error when maximum number of watches has been reached## Submitted by Tassilo `@tsdh`
**[Link to original bug (#753549)](https://bugzilla.gnome.org/show_bug.cgi?id=753549)**
## Description
Emacs now has the possibility to place watches on files and directories to get notified when they...## Submitted by Tassilo `@tsdh`
**[Link to original bug (#753549)](https://bugzilla.gnome.org/show_bug.cgi?id=753549)**
## Description
Emacs now has the possibility to place watches on files and directories to get notified when they change. It can do that on GNU/Linux systems either with plain inotify or via glib's GFileMonitor (which uses inotify under the hoods, too, at least on my system). In the latter case, there is the problem that g_file_monitor doesn't signal an error when the limit of watches a user may place is reached.
Here's a receipe:
1. As root, execute "sysctl fs.inotify.max_user_watches=0" to set the maximum number of watches a user is allowed to set to 0.
2. Validate that this setting works:
$ inotifywait .
Setting up watches.
Failed to watch .; upper limit on inotify watches reached!
Please increase the amount of inotify watches allowed per user via
`/proc/sys/fs/inotify/max_user_watches'.
3. Now the following glib api call
GError *err = NULL;
monitor = g_file_monitor (gfile, gflags, NULL, &err);
still returns a GFileMonitor and err won't be set. According to the docs, it should return NULL and set err in case of any error. And IMHO, reaching the limit is an error.
There is no way to figure out that the GFileMonitor won't work. It just looks like the watched file or directory never changes although it does.
I've had a brief look at the glib code and it seems that the error is at least considered in the low-level gio/inotify/*.c code but somehow is lost somewhere.
This is the bug about the issue I've filed for Emacs: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21241
Version: 2.44.xhttps://gitlab.gnome.org/GNOME/glib/-/issues/981inotify: send paired events to both sides2018-07-05T10:33:41ZBugzillainotify: send paired events to both sides## Submitted by Allison (desrt)
**[Link to original bug (#742849)](https://bugzilla.gnome.org/show_bug.cgi?id=742849)**
## Description
A file monitor on a directory could be prevented from seeing incoming
moves of files simply becau...## Submitted by Allison (desrt)
**[Link to original bug (#742849)](https://bugzilla.gnome.org/show_bug.cgi?id=742849)**
## Description
A file monitor on a directory could be prevented from seeing incoming
moves of files simply because of the existence of another unrelated file
monitor in the same process watching the source directory of the move.
This happens even if the affected monitor does not use the SEND_MOVED
flag (although the 'unrelated' one must be using it).
This works correctly, and reports both CREATED and DELETED events:
def show_event(mon, child, other, event):
print event
m0 = Gio.File.new_for_path('/a').monitor_directory (0, None)
m0.connect('changed', show_event)
but if this is also added:
m1 = Gio.File.new_for_path('/b').monitor_directory (Gio.FileMonitorFlags.SEND_MOVED, None)
then m0 will fail to report CREATED events for moves from /b to /a.
Let's fix that to avoid the 'spooky action at a distance' effect.https://gitlab.gnome.org/GNOME/glib/-/issues/932Problem directory monitoring was not working anymore2018-07-05T10:31:29ZBugzillaProblem directory monitoring was not working anymore## Submitted by Leandro
**[Link to original bug (#737461)](https://bugzilla.gnome.org/show_bug.cgi?id=737461)**
## Description
Hi,
I use the inotify functions from glib (through g_file_monitor_directory) with glib version 2.28. I u...## Submitted by Leandro
**[Link to original bug (#737461)](https://bugzilla.gnome.org/show_bug.cgi?id=737461)**
## Description
Hi,
I use the inotify functions from glib (through g_file_monitor_directory) with glib version 2.28. I upgraded to version 2.40 and directory monitoring was not working anymore.
Analyzing the problem, it seems to happen because I use an kenel 2.6.34-1 without the inotify_init1. The 2.40 version seems to check only for the presence of inotify_init1, it is not using inotify_init anymore. Although support using both seems possible as you can see bellow:
diff -u gio/inotify/inotify-kernel.c_old gio/inotify/inotify-kernel.c
--- gio/inotify/inotify-kernel.c_old 2014-09-18 10:54:53.060666721 -0300
+++ gio/inotify/inotify-kernel.c 2014-09-19 17:25:15.638938134 -0300
@@ -196,7 +196,9 @@
initialized = TRUE;
+#if defined(HAVE_INOTIFY_INIT1)
inotify_instance_fd = inotify_init1 (IN_CLOEXEC);
+#endif
if (inotify_instance_fd < 0)
inotify_instance_fd = inotify_init ();
-------------------------------------------------------------------------
diff -u gio/giomodule.c_old gio/giomodule.c
--- gio/giomodule.c_old 2014-09-19 16:54:53.747857935 -0300
+++ gio/giomodule.c 2014-09-19 16:56:05.256250125 -0300
@@ -1055,7 +1055,7 @@
/* Initialize types from built-in "modules" */
g_type_ensure (g_null_settings_backend_get_type ());
g_type_ensure (g_memory_settings_backend_get_type ());
-#if defined(HAVE_INOTIFY_INIT1)
+#if defined(HAVE_SYS_INOTIFY_H)
g_type_ensure (_g_inotify_directory_monitor_get_type ());
g_type_ensure (_g_inotify_file_monitor_get_type ());
#endif
-------------------------------------------------------------------------
diff -u configure.ac_old configure.ac
--- configure.ac_old 2014-09-18 10:54:52.935673027 -0300
+++ configure.ac 2014-09-19 16:52:08.513194513 -0300
@@ -1668,10 +1668,12 @@
dnl *****************************
dnl ** Check for inotify (GIO) **
dnl *****************************
+
inotify_support=no
AC_CHECK_HEADERS([sys/inotify.h],
[
- AC_CHECK_FUNCS(inotify_init1, [inotify_support=yes], [inotify_support=no])
+ inotify_support=yes
+ AC_CHECK_FUNCS(inotify_init1)
])
AM_CONDITIONAL(HAVE_INOTIFY, [test "$inotify_support" = "yes"])
thanks
Version: 2.41.xhttps://gitlab.gnome.org/GNOME/glib/-/issues/746GFileMonitor cease to emit events after monitored symlink on it is deleted.2024-02-17T20:46:42ZBugzillaGFileMonitor cease to emit events after monitored symlink on it is deleted.## Submitted by A.G.
**[Link to original bug (#706222)](https://bugzilla.gnome.org/show_bug.cgi?id=706222)**
## Description
Steps to reproduce:
1) create GFileMonitor for some directory - /tmp for example;
2) create symlink pointing...## Submitted by A.G.
**[Link to original bug (#706222)](https://bugzilla.gnome.org/show_bug.cgi?id=706222)**
## Description
Steps to reproduce:
1) create GFileMonitor for some directory - /tmp for example;
2) create symlink pointing to the same directory:
ln -s . test
3) create GFileMonitor for /tmp/test;
4) delete directory /tmp/test;
5) unref monitor for /tmp/test;
6) monitor for /tmp don't receive any events anymore.
The bug was reported for GLib 2.37, I've got the same behavior on 2.30, didn't test on any other versions.https://gitlab.gnome.org/GNOME/glib/-/issues/584file monitors, etc, should use the glib worker thread2024-02-09T09:14:31ZBugzillafile monitors, etc, should use the glib worker thread## Submitted by Dan Winship `@danw`
**[Link to original bug (#681326)](https://bugzilla.gnome.org/show_bug.cgi?id=681326)**
## Description
Most of the file monitor implementations, plus some of the volume stuff, and probably one or ...## Submitted by Dan Winship `@danw`
**[Link to original bug (#681326)](https://bugzilla.gnome.org/show_bug.cgi?id=681326)**
## Description
Most of the file monitor implementations, plus some of the volume stuff, and probably one or two other things run some things in the default GMainContext, leading to documentation warnings like:
* (though if the global default main context is blocked, this may
* cause notifications to be blocked even if the thread-default
* context is still running).
These things should be rewritten to use the glib worker thread instead.2.82https://gitlab.gnome.org/GNOME/glib/-/issues/576unable to monitor access time changes2023-09-01T10:17:36ZBugzillaunable to monitor access time changes## Submitted by William Jon McCann
**[Link to original bug (#680340)](https://bugzilla.gnome.org/show_bug.cgi?id=680340)**
## Description
Nautilus displays access time in various places in the interface. These values are often a lie...## Submitted by William Jon McCann
**[Link to original bug (#680340)](https://bugzilla.gnome.org/show_bug.cgi?id=680340)**
## Description
Nautilus displays access time in various places in the interface. These values are often a lie because we don't get any information from GIO about changes.
The inotify code seems to explicitly ignore IN_ACCESS events.
### Blocking
* [Bug 145255](https://bugzilla.gnome.org/show_bug.cgi?id=145255)https://gitlab.gnome.org/GNOME/glib/-/issues/521If the interval between missing directory creation and file creation under th...2018-06-08T12:57:36ZBugzillaIf the interval between missing directory creation and file creation under the directory is short, gfilemonitor cannot get the create event of file under the directory.## Submitted by changbin
**[Link to original bug (#671518)](https://bugzilla.gnome.org/show_bug.cgi?id=671518)**
## Description
Created attachment 209127
0001-add-filemonitor-test.patch, a test patch for glib, to detect the file cha...## Submitted by changbin
**[Link to original bug (#671518)](https://bugzilla.gnome.org/show_bug.cgi?id=671518)**
## Description
Created attachment 209127
0001-add-filemonitor-test.patch, a test patch for glib, to detect the file changes of a missing directory
1. Create a gfilemonitor testcase, in order to detect the file changes of a missing directory.
a) add patch "0001-add-filemonitor-test.patch" for glib package, based on commit number "6e8caec6d9af06d4f7f0e6cd1a86c6c47e49ff01"
b) build glib package
c) run glib/gio/tests/testgfilemonitor.
2. copy "file_monitor_test.sh" & "file_monitor_test.sh" under /tmp
3. run "file_monitor_test.sh"
Filemonitor gets create event of missing directory, but cannot get the create event of files under this directory.
**Patch 209127**, "0001-add-filemonitor-test.patch, a test patch for glib, to detect the file changes of a missing directory":
[0001-add-filemonitor-test.patch](/uploads/6476e237a6e4e917d130cbef237030f9/0001-add-filemonitor-test.patch)
Version: 2.31.xhttps://gitlab.gnome.org/GNOME/glib/-/issues/463glib trying to put inotify watch on old directory2018-07-05T11:15:46ZBugzillaglib trying to put inotify watch on old directory## Submitted by Patrick H
**[Link to original bug (#661619)](https://bugzilla.gnome.org/show_bug.cgi?id=661619)**
## Description
Created attachment 198900
gdb stack trace of firefox being hung
I'm bringing this bug from firefox (ht...## Submitted by Patrick H
**[Link to original bug (#661619)](https://bugzilla.gnome.org/show_bug.cgi?id=661619)**
## Description
Created attachment 198900
gdb stack trace of firefox being hung
I'm bringing this bug from firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=692545).
What appears to be happening is that when using a GTK file selection dialog, an inotify watch is being added to the directory, and then after the dialog is closed, glib still tries to keep the inotify watch on the directory as a result of im_scan_missing(). This can result in the application hanging if the inotify watch is being put on an autofs mount which is no longer available (the watch hangs until automount returns).
This behavior has been observed in firefox and evince.
I am including 3 attachments.
The first is a stack trace of firefox being hung after the autofs mount becomes unavailable. The file selection dialog had been closed, and there are no open file handles on the mount point. I simulated the mount going unavailable by unmounting and then putting in an iptables DROP rule for traffic to the network share.
The second attachment is firefox opening the file selection dialog with a break point on ip_watched_dir_new.
The third attachment is also a break point on ip_watched_dir_new, but this break triggered a few seconds after the mount was unmounted and made unavailable.
**Attachment 198900**, "gdb stack trace of firefox being hung":
[firefox_hang.txt](/uploads/d37d5779f302c056a415b36b2e1e5733/firefox_hang.txt)
Version: 2.28.xhttps://gitlab.gnome.org/GNOME/glib/-/issues/461inotify notification backend doesn't detect early created files in new subdir2018-07-05T10:35:22ZBugzillainotify notification backend doesn't detect early created files in new subdir## Submitted by Alexander Larsson `@alexl`
**[Link to original bug (#661162)](https://bugzilla.gnome.org/show_bug.cgi?id=661162)**
## Description
If you do
rm -rf /tmp/noexist/
gvfs-monitor-dir /tmp/noexist
and then in another she...## Submitted by Alexander Larsson `@alexl`
**[Link to original bug (#661162)](https://bugzilla.gnome.org/show_bug.cgi?id=661162)**
## Description
If you do
rm -rf /tmp/noexist/
gvfs-monitor-dir /tmp/noexist
and then in another shell:
mkdir /tmp/noexist; mkdir /tmp/noexist/subdir
Then the monitor will only detect the creation of the noexist dir.
However if you instead do:
mkdir /tmp/noexist; sleep 10; mkdir /tmp/noexist/subdir
Then it will also detect the creation of subdir.
This is a race in the handling of non-existing directories. If we suddenly detect that the directory exists, then we need to readdir it after we have created an inotify monitor for it, since things could have been added to it before we created the monitor.https://gitlab.gnome.org/GNOME/glib/-/issues/446new subscriptions can report old events from an existing directory watch2018-06-08T12:58:19ZBugzillanew subscriptions can report old events from an existing directory watch## Submitted by Peter Clifton
**[Link to original bug (#658491)](https://bugzilla.gnome.org/show_bug.cgi?id=658491)**
## Description
I've been having some issues with file-change monitoring, where I hook up a GFileMonitor to a file ...## Submitted by Peter Clifton
**[Link to original bug (#658491)](https://bugzilla.gnome.org/show_bug.cgi?id=658491)**
## Description
I've been having some issues with file-change monitoring, where I hook up a GFileMonitor to a file just after having changed it on disk. This only occurs in the case where a second monitor exists on the directory in question. (In this case, left hanging around due to a possible bug in the GTK file-chooser).
It appears that the GIO backend code has a bit of a race, in that it can queue up events for a directory - then process them at some later time (after my new subscription is added).
The OLD events match against the new subscription, and are dispatched - despite the events predating the subscription.
Should adding a new subscription force processing of any events up to that point (before adding the new subscription), or would this be something that could be handled by looking at the timestamp on the events?
Version: 2.28.xhttps://gitlab.gnome.org/GNOME/glib/-/issues/376Remove the virtual emission of G_FILE_MONITOR_EVENT_CHANGES_DONE_HINT2018-07-05T10:35:34ZBugzillaRemove the virtual emission of G_FILE_MONITOR_EVENT_CHANGES_DONE_HINT## Submitted by Aleksander Morgado
**[Link to original bug (#635765)](https://bugzilla.gnome.org/show_bug.cgi?id=635765)**
## Description
G_FILE_MONITOR_EVENT_CHANGES_DONE_HINT is currently issued in two cases:
* If a file is updat...## Submitted by Aleksander Morgado
**[Link to original bug (#635765)](https://bugzilla.gnome.org/show_bug.cgi?id=635765)**
## Description
G_FILE_MONITOR_EVENT_CHANGES_DONE_HINT is currently issued in two cases:
* If a file is updated, not closed, and the last update happened more than 2 seconds ago (hardcoded value).
* If a file is updated and closed.
The 2 second delay could be configurable, and also possible to fully disable passing 0 as delay, so that CHANGES_DONE_HINT is only issued once a file has been closed after an update.
Version: 2.27.xhttps://gitlab.gnome.org/GNOME/glib/-/issues/362GFileMonitor doesn't monitor root directory "/" (with test case)2018-06-08T12:58:30ZBugzillaGFileMonitor doesn't monitor root directory "/" (with test case)## Submitted by Hong Jen Yee
**[Link to original bug (#633014)](https://bugzilla.gnome.org/show_bug.cgi?id=633014)**
## Description
Created attachment 173108
A simple test case demonstrating the bug.
I found that g_file_monitor_dir...## Submitted by Hong Jen Yee
**[Link to original bug (#633014)](https://bugzilla.gnome.org/show_bug.cgi?id=633014)**
## Description
Created attachment 173108
A simple test case demonstrating the bug.
I found that g_file_monitor_directory is not able to monitor "/".
I'm using glib 2.26 on Ubuntu 10.10.
uname -a output: Linux thinkpad 2.6.35-22-generic #34-Ubuntu SMP Sun Oct 10 09:24:00 UTC 2010 i686 GNU/Linux
In the attachment is a simple test case demonstrating this bug.
Just pass "/" as argv[1] to this test program, and do some changes inside /.
Then you'll see nothing happens. No notification for any event is sent.
If you pass your home directory or others, it works correctly.
The test case (also included in attachment):
#include <gtk/gtk.h>
#include <gio/gio.h>
static void on_changed(GFileMonitor *monitor,
GFile *file,
GFile *other_file,
GFileMonitorEvent event_type,
gpointer user_data)
{
char* name = g_file_get_parse_name(file);
g_debug("changed: %s", name);
g_free(name);
}
int main(int argc, char** argv)
{
gtk_init(&argc, &argv);
if(argc > 1)
{
GFile *gf = g_file_new_for_path(argv[1]);
GFileMonitor* mon = g_file_monitor_directory(gf, 0, NULL, NULL);
g_signal_connect(mon, "changed", G_CALLBACK(on_changed), NULL);
g_object_unref(gf);
gtk_main();
g_file_monitor_cancel(mon);
g_object_unref(mon);
}
return 0;
}
**Attachment 173108**, "A simple test case demonstrating the bug.":
[test.c](/uploads/6961033930dc38778a022ab49e27e1d6/test.c)
Version: 2.26.x