On Tue, Jun 7, 2011 at 10:52 PM, <ya3p5e7pz8@xxxxxxxxxxx> wrote:
> Hi there,
>
> I'm the author of jpathwatch [1], a Java library that provides
> directory watching capability to Java programs. The library is
> cross-platform and supports Linux as well as Windows, OSX and FreeBSD.
> The library implements JDK7's WatchService API, but can also be used
> in JDK5 and JDK6 programs.
>
> For the API I'm providing (which I cannot really change), I need to
> distinguish between files that are renamed within the same directory
> ('local' renames), and files that are moved into and out of the
> watched directory ('foreign' renames). Local and foreign renames map
> to different events:
> * local renames show up as such, as RENAME_FROM and RENAME_TO events
> * foreign renames show up as CREATE and DELETE events.
>
> The problem I'm now having is that from an IN_MOVE_FROM event alone I
> cannot tell whether it is a local or a foreign rename. One (bad)
> solution in userland would be to wait for a matching IN_MOVE_TO. In
> case of a foreign rename this event will never happen, so I'd have to
> hold back the IN_MOVE_FROM until some timeout and then send send it as
> DELETE; for local renames I'd receive IN_MOVE_TO and would send
> RENAME_FROM and RENAME_TO.
> But obviously that solution is poor, so I'm wondering if some
> enhancement in inotify that indicates foreign renames in events could
> help (or if I'm missing something obvious here and am just typing
> gibberish :)
>
> So in conclusion:
> * Am I missing something? Is there really no way to tell local from
> foreign renames in inotify?
I don't think you are missing anything with regards to inotify.
> * If I'm not, I propose to add a flag mask bit to indicate this
> situation, similar to the IN_ISDIR flag in the mask field - let's call
> it IN_ISFOREIGN. Whenever this bit is set on an IN_MOVE_FROM event,
There is already a RENAME flag, that the generic kernel fsnotify
sets on a 'local' rename, see:
85static inline void fsnotify_move(struct inode *old_dir, struct
inode *new_dir,
86 const unsigned char *old_name,
87 int isdir, struct inode *target,
struct dentry *moved)
88{
89 struct inode *source = moved->d_inode;
90 u32 fs_cookie = fsnotify_get_cookie();
91 __u32 old_dir_mask = (FS_EVENT_ON_CHILD | FS_MOVED_FROM);
92 __u32 new_dir_mask = (FS_EVENT_ON_CHILD | FS_MOVED_TO);
93 const unsigned char *new_name = moved->d_name.name;
94
95 if (old_dir == new_dir)
96 old_dir_mask |= FS_DN_RENAME;
97
98 if (isdir) {
99 old_dir_mask |= FS_ISDIR;
100 new_dir_mask |= FS_ISDIR;
101 }
102
But the inotify backend masks this flag from the user.
The older dnotify backend does pass this flag to the user,
so if dnotify gives you everything you need you can use it
instead of inotify, or I suppose you can use them both?
* disclaimer - I am not an expert in this area, I just happened
to play with inotify once.
> the user program knows that it won't have to look for a matching
> IN_MOVE_TO in the same directory. Same could be done for IN_MOVE_TO
> (although it's not entirely necessary, but it would make sense just
> for symmetry)
>
> Cheers,
>
> Uwe Pachler
>
> [1] http://jpathwatch.wordpress.com/
>
> P.S.: Sorry for the wonky email address; I'm SPAM paranoid
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
