mirror of
https://gitlab.gnome.org/GNOME/glib.git
synced 2024-11-11 03:46:17 +01:00
3d2d4b8efe
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. |
||
|---|---|---|
| .. | ||
| ginotifydirectorymonitor.c | ||
| ginotifydirectorymonitor.h | ||
| ginotifyfilemonitor.c | ||
| ginotifyfilemonitor.h | ||
| inotify-helper.c | ||
| inotify-helper.h | ||
| inotify-kernel.c | ||
| inotify-kernel.h | ||
| inotify-missing.c | ||
| inotify-missing.h | ||
| inotify-path.c | ||
| inotify-path.h | ||
| inotify-sub.c | ||
| inotify-sub.h | ||
| Makefile.am | ||