inotify: send CHANGES_DONE when new files 'appear'
authorRyan Lortie <desrt@desrt.ca>
Thu, 15 Jan 2015 16:08:35 +0000 (11:08 -0500)
committerRyan Lortie <desrt@desrt.ca>
Fri, 20 Mar 2015 16:01:34 +0000 (12:01 -0400)
commit3d2d4b8efe44af1da7206b10e4565e59dbdb5121
tree1ac4e8eaefe07cd52991f3c3d959e353db2a80a0
parent2737ab3201163631be152801a859b3874a667f10
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.
gio/inotify/inotify-helper.c