Emit modify only if the file isn't changing anymore
SpartanJ opened this issue · comments
Original report by Bernhard Friedreich (Bitbucket: [Bernhard Friedreich](https://bitbucket.org/Bernhard Friedreich), ).
When copying files into a watched directory the modified event is emitted regularly until the file is finished. It would be great to have only one modify event at the end as long as the file is still being worked on. Maybe you could implement to wait one modify interval if the event reoccurs - if it does wait another one - if it doesn't the modify (should be) finished.
My usecase is a photo indexer which can't work on a partial photo/video.
Happens with linux backend (inotify) and Generic backend (I guess it is good that both are behaving the same :) )
Thanks for this library! It is the best I was able to find after many hours of search.
Original comment by Martín Lucas Golini (Bitbucket: SpartanJ, GitHub: SpartanJ).
Hi Bernhard!
Sorry for the huge delay, i was on vacations and then forgot to answer.
I thought about adding something like that. I think the same as you, it would be really useful, since the most use cases i think need the notification when the file ends being copied/move. The problem is that not all the OSes that efsw supports provide this information and i don't want to add features that are partially supported. In the case of Linux it could be supported by filtering the IN_CLOSE_NOWRITE and IN_CLOSE_WRITE notifications, it's a super easy change. But for Windows i can only know the last access and last write to a file ( we can know this in any OS, of course ). As you said, it's possible to guess if the job finished, waiting some arbitrary time after the last write/access, but it would be a guess, and it simply could be wrong, for your use case i think it should work. I recommend you to just do that but from you app side, it should be easy to implement. I don't want to do that form my side because it would add complexity to something that i can't guaranteed that works all the times.
Also to add more info:
On OS X: FSEvents does not provided this information.
On BSD: KQueue does not provided this information.
On Windows: USN Journal could provided this information for NTFS.
I'll have to close this issue since i sadly cannot implement it correctly.
Thanks,
Regards