Subscribe to IN_MODIFY events for Inotify about efsw HOT 8 CLOSED

Original comment by Martín Lucas Golini (Bitbucket: SpartanJ, GitHub: SpartanJ).

I don't understand how it doesn't work for you, i think that i need a better explanation on how your software works, the 30 seconds delay sounds fine, but, it should wait since Add to Modified ( sine modified event is emitted after the file descriptor close call ), and then, you should wait 30 seconds.
IN_MODIFY will emit a event on every write call, you don't need that to know if the file finished copying, with the Modified event is enough ( in this case is IN_CLOSE_WRITE ).

Case 1: It's correct, and should be enough for you. Just detect the new files ( Add ), and wait to the Modified event, then you can upload it to the cloud.

Case 2:
No IN_MODIFIED is required, there are two events for movement: IN_MOVED_TO and IN_MOVED_FROM. You'll see Add and Delete when is moved to another folder, or the software just do that. It seems that for this IN_CLOSE_WRITE is not emitted, i've nothing to do about it.

Just let me know if i understood correctly.

from efsw.

Original comment by Mihail Slobodyanuk (Bitbucket: mihail_slobodyanuk, ).

Just tried modified case 2. It seems case above sometimes generated Add then Delete but sometimes only Moved.

The changes is:

mv /1/file /2

where watch established only on /2 folder.
It will generate only Add event and no Modify after.
but inotifywait show MOVED_TO event
How to differentiate it than case 1 ?

from efsw.

Original comment by Martín Lucas Golini (Bitbucket: SpartanJ, GitHub: SpartanJ).

Oh, you're right in that case, i should emit also a Modified after the Add to fulfill your requirements.
I'm not sure if IN_MODIFY should be added, since it can be confusing, i need to see how this is reported in windows and os x, since i don't remember right now.

from efsw.

Original comment by Martín Lucas Golini (Bitbucket: SpartanJ, GitHub: SpartanJ).

Added the modified event for that case:
https://bitbucket.org/SpartanJ/efsw/commits/10915979ce6957bc1639cab6470d67f9c49e48c7

from efsw.

Original comment by Mihail Slobodyanuk (Bitbucket: mihail_slobodyanuk, ).

Case 1: It's correct, and should be enough for you. Just detect the new files ( Add ), and wait to the Modified event, then you can upload it to the cloud.

It seems i don't need to handle 'Add' action? Looks like 'Modify', 'Move' and 'Delete' is enough.

Also just FUI. File modify operation can be in 'long open' mode like:

#!bash

dd if=/dev/urandom bs=1M count=1500 of=file

and in 'short open'

#!bash

while true ; do  echo "1234" >> asd; sleep 0.05; done

Both cases are same for end user side and should be handled in same at the end

from efsw.

Original comment by Martín Lucas Golini (Bitbucket: SpartanJ, GitHub: SpartanJ).

No, they are not the same. The echo is opening, writing and closing the file, that's why you get constants modified, because the file is being opened and closed every time. A normal file copy NEVER closes the file on every write.

I still don't see the point to add IN_MODIFIED event report, but you are free to fork the library :)

May be this can be added as an optional parameter, but i prefer to keep the library as clean as possible. I will take a look on how it's reported this case in Windows and OS X, because i don't remember, for the moment i won't make any change.

Regards!

from efsw.

Original comment by Mihail Slobodyanuk (Bitbucket: mihail_slobodyanuk, ).

Agree. It's not the same on system level. But 3rdparty programs can implement both cases. And I need take into account both.

I am don't press you to add IN_MODIFIED. The more I do not know a similar behavior on Windows and wanted discuss with you is current behavour is enough. It seems yes.

Thank you!

from efsw.

Original comment by Martín Lucas Golini (Bitbucket: SpartanJ, GitHub: SpartanJ).

I'm totally open to suggestions, and yours was totally reasonable.

In your use case, just wait 30 seconds after the last Modified event, that should be enough to ensure the file copy is complete.

Regards!

from efsw.