search

dmatveev / libinotify-kqueue

NetBSD Google Summer of Code 2011 project (#2)
Other
35 stars 7 forks source link

The deletion events are not provided in time #12

Closed dmatveev closed 1 year ago

dmatveev commented 10 years ago 
 $ 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.

xaionaro commented 10 years ago

Can this be related to #11?

dmatveev commented 10 years ago

Probably, I'm now working on this.

xaionaro commented 10 years ago

Please tell if we can help with testing. We will have time for that in Monday.

dmatveev commented 10 years ago

Ok, thanks!

dmatveev commented 10 years ago

Still observing some issues.

dmatveev commented 10 years ago

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.

dmatveev commented 10 years ago

Yep, it is really there. Will rework the event processing routines soon.

wulf7 commented 10 years ago

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:

  1. create brain-damaged structure called worker-sets.
  2. Lose events firing while other event is being processed by library. Most often lose NOTE_WRITE on a watched directory
dmatveev commented 10 years ago

Wow, cool. Why you did not send any comments/pull requests for that?

wulf7 commented 10 years ago

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

wulf7 commented 10 years ago

This project LOOKED like "wrote and forgot" not LOOKS. My bad. Sorry

dmatveev commented 10 years ago

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.

wulf7 commented 10 years ago

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 :-(

wulf7 commented 10 years ago

I hope to publish first part of changes within a week

dmatveev commented 1 year ago

Closing as no longer applicable as @wulf7 stole the show. :)

dmatveev commented 1 year ago

For the curious minds: https://github.com/libinotify-kqueue/libinotify-kqueue