Web lists-archives.com

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

Hash: SHA1

On 14/01/15 23:00, Ryan Lortie wrote:
> I'm making substantial modifications to the file monitoring system in
> GIO.  I've gotten to the point where I feel comfortable pushing a branch
> that contains the main ideas:
>   https://git.gnome.org/browse/glib/log/?h=wip/mount-watcher
> It's not even vaguely tested or stable and will probably crash under
> anything more than the most trivial of uses.  Work will continue over
> the next days.
> The private API between GIO and the internal file monitor backends has
> changed substantially.  See the commit message for details about that. 
> This means that all of the backends will need non-trivial changes.  I've
> already made the required modifications to the inotify backend.  I plan
> to move next to the kqueue backend and I could probably even tackle the
> FAM and win32 backends myself.
> I have no means of testing changes to the 'fen' backend (Solaris).
> It would be awesome if someone with a Solaris box and some free time
> could port the fen backend to the new changes.  If nobody comes forward,
> we will probably remove the backend.

I might be a bit offtopic, but I saw "file monitor rewrite" and I had to
jump in...

Currently GFileMonitor doesn't have a unique way to know whether a file
got closed. There is the changes-done-hint event, but that covers IIRC 2
things: files getting closed and also a "virtual" emission which happens
after some time even if the files were not closed (think of a log file
which never gets closed). The main issue is that if you want to get
notified of when a file was fully updated *and* closed, you need to
fallback to raw inotify. The rationale for wanting to get notified only
when the file got closed is e.g. Tracker monitoring the Downloads/
directory. We may not want to extract file info for an ongoing download,
just for when the download is fully finished (and destination file
closed). More background here:

alexl noted that non-Linux systems may not have support to notify files
closed, so removing the changes-done-hint virtual emission wasn't an
option in GLib. Still, I think that the original (obsoleted) patch in
that bugreport (which allows to at least disable the virtual emission
via a property) may be useful for Linux/inotify users. For other
backends we could just ignore the disabling possibility...

- -- 
Version: GnuPG v2

gtk-devel-list mailing list