On Wed, Jun 8, 2011 at 5:30 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> 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.
Sorry, *not* to IN_ALL_EVENTS, it's a 'special' flag,
not an event.
>
> 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
