On Wed, Jun 8, 2011 at 4:33 PM, <ya3p5e7pz8@xxxxxxxxxxx> wrote:
> Hi Amir,
>
> Thanks for your response!
>
> On Wed, Jun 8, 2011 at 2:41 PM, Amir Goldstein amir73il-at-gmail.com
> |kernel.org/Allow_neo-media| <wraekx8rrt@xxxxxxxxxxxxxx> wrote:
>> 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.
>
> That's quite a bummer; I originally decided for inotify because it is
> the newer interface; I hadn't expected it to have less features than
> dnotify. I've also already implemented the inotify backend for
> jpathwatch; I only just discovered that it behaves odd because of the
> behaviour I described above.
>
>> 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?
>
> I guess using them both won't really work; I'd either have to switch
> everything to dnotify or hope for changes to inotify so that at least
> future versions of jpathwatch can detect foreign renames and behave
> correctly...
>
> But from what you're saying it appears almost trivial to add the flag
> I proposed to inotify;
It could be simple.
I see that the FS_RENAME bit (0x10000000) is not being used by inotify:
http://lxr.linux.no/linux+v2.6.39/include/linux/inotify.h#L51
So you *may* just need to define IN_RENAME and add it to
IN_ALL_EVENTS and INOTIFY_ALL_BITS.
Then again, there may be more to it...
> if it turns out that simple to do I might even
> do it myself and submit a patch (given that there is a chance it will
> make it into the main stream kernel).
>
If you won't do it, probably nobody else will ;-)
> Is there some process I have to follow or people I need to talk to
> (othre than posting on this list)?
You should follow the (somewhat strict) patch submission rules:
http://lxr.linux.no/linux+v2.6.39/Documentation/development-process/
And send your patch to the maintainers (CC linux-fsdevel):
http://lxr.linux.no/linux+v2.6.39/MAINTAINERS#L3202
Don't worry! if your case is solid and your patch works
and doesn't break anything, you should be fine.
Good luck,
Amir.
>
>>
>> * 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
>>
>
> Cheers,
>
> Uwe
>
--
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
