#1 spurious ENTRY_RENAME_FROM/TO on Linux

[Uwe Pachler]

On Linux ,when requesting the ENTRY_RENAME_FROM, ENTRY_RENAME_TO, ENTRY_CREATE and ENTRY_DELETE event kinds, jpathwatch will report files moved into the watched directory (that is: files that existed outside before) as ENTRY_RENAME_TO instead of ENTRY_CREATE.

This will be hard to fix, because there appears to be no way to tell for a single IN_RENAME_TO inotify event whether it belongs to a 'local' rename (a rename occorring within the watched directory) or a 'foreign' rename (a rename into/out of the watched directory).

The only way to check is to see if the cookies for an IN_RENAME_TO/IN_RENAME_FROM match - which, after receiving IN_RENAME_FROM, involves waiting for IN_RENAME_TO - but this event may not come, so we'll require a timeout (yuk).
Unless there is some other way to do this on Linux that I missed...

[Uwe Pachler]

Ok, here's some news on this issue: I had a conversation with people on the linux-fsdev mailing list [1], and it appears that fanotify, the kernel subsystem that inotify and dnotify are based (at least as of recently), does indeed support a flag that indicates whether a rename was local or foreign.

In the conversation, a developer indicated to use dnotify (the inotify predecessor), as it exposes this flag (inotify does not). However, dnotify is the inferior API and actually has some severe issues [2]

So in conclusion, I'll be looking at hacking inotify in the Linux kernel to expose said flag; this will not only benefit jpathwatch but everyone else as well.

Cheers,

Uwe

[1] http://marc.info/?l=linux-fsdevel&m=130754450101335&w=2
[2] http://www.kernel.org/pub/linux/kernel/people/rml/inotify/README