First release of pyfsevents

[Aahz]

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....
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"To me vi is Zen.  To use vi is to practice zen.  Every command is a
koan.  Profound to the user, unintelligible to the uninitiated.  You
discover truth everytime you use it."  --reddy at lion.austin.ibm.com