First release of pyfsevents

exarkun at exarkun at
Tue Sep 8 04:14:22 CEST 2009

On 12:57 am, aahz at wrote:
>In article <d103be2b-3f1e- 
>46f3-9a03-46f7125f5579 at>,
>Nicolas Dumazet  <nicdumz at> wrote:
>>On Sep 3, 10:33=A0pm, a... at (Aahz) wrote:
>>>I'm curious why you went with FSEvents rather than kqueue. My company
>>>discovered that FSEvents is rather coarse-grained: it only tells you 
>>>there has been an event within a directory, it does *not* tell you
>>>anything about the change!
>>It depends what you want to do with your events. In my case, knowing
>>that an event occurred in a directory is sufficient because I already
>>know the state of the directory.  If you look in the examples/ folder,
>>(watcher) you'll find that with very little work, you can maintain a
>>directory snapshot in memory and compare it against the new state of
>>the directory to know exactly what happened, when necessary.
>>kqueue has the limitation that kern.kq_calloutmax is usually set
>>at 4096. Meaning that one could not use this on a big (Mercurial)
>>repository with 5k files. FSEvents on the other hand saves us the
>>trouble to have to register each file individually.  Also, I am not
>>quite sure if we can use kqueue to register a directory, to be warned
>>when a file is created in this directory.
><sigh>  %(obscenity)s  I didn't realize that you had to register each
>file individually with kqueue.  We were hoping to avoid having to write
>watcher code because that is not reliable for renames (especially
>multiple renames in quick succession).
>Maybe we'll try using /dev/fsevents directly....

Just a guess, but since the kqueue interface is based on file 
descriptors, not on file names, following renames reliably shouldn't be 
a problem with it.  If someone knows about this for sure though, it'd be 
nice to hear about it. :)  All of the kqueue documentation I've seen has 
been rather incomplete.


More information about the Python-list mailing list