Re: File monitor rewrite: Solaris (and other) help wanted

[Ryan Lortie <desrt desrt ca>]

hi,

On Wed, Jan 14, 2015, at 20:49, Christian Hergert wrote:
> Does anything rely on the delay that happens in the current system? For
> example, is it used to coalesce an open(O_CREAT)/rename() into a single
> signal emission?

I know I've written some things in the past where I've been a bit
worried about getting notified too often and though to myself "well,
it's OK -- GFileMonitor is slow anyway...".  That's my biggest concern.

As for functionality, the typical write-and-rename approach appears
today as:

  create x.tmp
  change x.tmp
  changes-done x.tmp
  rename x.tmp -> x

and it will appear exactly that way in the future.

On my TODO list is to add O_TMPFILE support to g_file_set_contents(),
but I sort of want not to do it.  I'm afraid that this is going to suck
a little bit in terms of how notifications work because inotify reports
link() the same as creat().  Normally with creat() we also see the
close() event (changes-done) but with link() no such event will show up,
so we'll end up generating one for ourselves two seconds later.  It
seems to be some sort of fail in the kernel that these two cases are
considered equivalent.  At least renames are their own event...

Cheers