libinotify-kqueue
libinotify-kqueue copied to clipboard
dmatveev
The deletion events are not provided in time
$ gcc test.c -L.libs -I. -linotify -o test
$ test /tmp/test
$ touch /tmp/test/1
$ touch /tmp/test/2
$ rm /tmp/test/1
$ rm /tmp/test/2
The IN_DELETE notification for 2 will be sent only when something else will occur in the directory.
Please tell if we can help with testing. We will have time for that in Monday.
Yepp. Looks like there is a misuse of EV_ONESHOT, with this flag NOT set, the changes in directory are being detected correctly, but other issues appear. Will investigate/fix it later.
No need to rework. It has been done already by myself about a year ago. Now I settled resulting code on my GH page. Take a look on it On topic: Using EV_ONESHOT instead of EV_CLEAR led this project to make 2 bad things:
- create brain-damaged structure called worker-sets.
- Lose events firing while other event is being processed by library. Most often lose NOTE_WRITE on a watched directory
As many other GSOC projects this one looks like "wrote and forgot" one that time. And my code was not in good shape to be published. But since I had to resolve conflicts on update of port system in devel/libinotify directory I decided to blow the dust off my old work and spend some time to make it ready for publishing
Actually, I was in army in 2012-2013, so really there were no commits. Though the people who were really interested in the project contacted me by e-mail and I'd collected some feedback. I have planned to do benchmarking and refactoring work, but now I have time only for bugfixing (still, it takes weeks to get a single issue resolved). The ONESHOT<-->CLEAR is a really idiotic one, I agree.
I've took a brief look on the list of your changes (just commit messages, no code review), and it looks pretty interesting. It seems you've implemented the things I've been thinking about from time to time.
I am fine with integrating your changes into the main branch, if it does not break the portability. What is about making a series of pull-requests so I could review the actual changes sequentially? I see that your code is rebased with my recent changes, so there should not be many problems.
Ok. I'll try to rearrange my commits to be a logical independent series of changes. But it's a long term task due to one reason: There were transition from monolithic array called worker-sets with its 1:1:1 relation between kqueue changes, kqueue (sub)watches and (sub)files to a linked list of inotify watches with its m:n indirect (via inode number) relation between watches and files. So moving a source code through this (fuzzy) fence leads to its (code) rewrite :-(
For the curious minds: https://github.com/libinotify-kqueue/libinotify-kqueue