Re: incron not seeing IN_CLOSE_WRITE?

On Fri, Dec 10, 2010 at 11:54:43PM +0100, Lukas Jelinek wrote:
> Hi,
>
> I can't understand well what do you ask for. But I can to explain how it
> works. The kernel emits IN_CLOSE_WRITE or IN_CLOSE_NOWRITE in dependence
> whether the file was open for writing or not. For example:
>
> FILE* f = fopen("file.txt", "w");
> ...
> fclose(f);
>
> This code emits IN_CLOSE_WRITE. And this code:
>
> FILE* f = fopen("file.txt", "r");
> ...
> fclose(f);
>
> ...emits IN_CLOSE_NOWRITE. If you want to monitor only one of these
> events then use IN_CLOSE_WRITE or IN_CLOSE_NOWRITE respectively. But if
> you want to monitor both of these events you must use both of those
> bitmasks (which means IN_CLOSE_WRITE | IN_CLOSE_NOWRITE in C/C++ code
> and IN_CLOSE_WRITE,IN_CLOSE_NOWRITE in the incron table) or simply
> IN_CLOSE. In other words, IN_CLOSE is only a combined (ORed) mask for
> monitoring, not an event type itself. The same applies for IN_MOVE
> (which combines IN_MOVED_FROM and IN_MOVED_TO) and IN_ALL_EVENTS (which
> combines all monitorable events).

That is consistent with my understanding.

> Is it clear? If not please specify your question a more understandable way.

Yes, that's perfectly clear. What's not perfectly clear is why some other
inotify-related tools are reporting inconsistent things about the same file
operation (the copy). I'm trying to get to the bottom of why incron isn't
firing on the IN_CLOSE_WRITE that I'm expecting it to see when the file copy
happens. That's my question basically.

If IN_CLOSE is just a macro which ORs IN_CLOSE_NOWRITE and IN_CLOSE_WRITE,
why do some tools report it as the event they see instead of
IN_CLOSE_NOWRITE or IN_CLOSE_WRITE?

And most strange of all, why does my incron job for the IN_CLOSE_WRITE on
the file that is being copied to fire once when I start or restart incron,
but not again?

If there's anything further I can do to debug this, please let me know. If
you'd like me to give you a contained way of reproducing this, I can do that
too.

regards

Andrew
Received on Tue Jun 05 2012 - 22:14:21 CEST