First release of pyfsevents

[exarkun at twistedmatrix.com]

On 12:57 am, aahz at pythoncraft.com wrote:
>In article <d103be2b-3f1e- 
>46f3-9a03-46f7125f5579 at r5g2000yqi.googlegroups.com>,
>Nicolas Dumazet  <nicdumz at gmail.com> wrote:
>>On Sep 3, 10:33=A0pm, a... at pythoncraft.com (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 
>>>that
>>>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.
>
>Thanks!
>>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.

Jean-Paul