Re: [Qemu-devel] [PATCH 2/3] usb-mtp: Add support for inotify based file monitoring

[Bandan Das]

Gerd Hoffmann <address@hidden> writes:

> On Mo, 2015-11-09 at 18:12 -0500, Bandan Das wrote:
>> Gerd Hoffmann <address@hidden> writes:
>> 
>> > On Di, 2015-11-03 at 19:00 -0500, Bandan Das wrote:
>> >> +                    /* Add a new watch asap so as to not lose events
>> >> */
>> >
>> > This comment sounds like there is a race ("asap").  There isn't one,
>> > correct ordering (adding the watch before reading the directory) is
>> 
>> Hmm, seems like there's still a small window. We may not have even
>> started processing the event because we are still processing the earlier
>> ones.
>
>> > enough to make sure you don't miss anything.  You might see create
>> > events for objects already in the tree though, are you prepared to
>> > handle that?
>> 
>> Oh, interesting.  Current version will happily add duplicate entries.
>> I will add a check.
>
> I think we are talking about the same thing here.
> Things can run in parallel, like this:
>
>     process copying a file tree | qemu with usb-mtp
>     ----------------------------+--------------------------
>     create directory            |
>                                 | inotify event #1 queued (dir)
>                                 | qemu fetches event #1
>                                 | qemu adds new inotify watch
>     copy file into new dir      |
>                                 | inotify event #2 queued (file)
>                                 | qemu reads new directory
>                                 | qemu finds the new file
>                                 | qemu fetches event #2
>
> So, yes, the kernel can add new inotify events for the new watch before

Maybe I am missing something but what if the watch on dir was
added by qemu _after_ the file (say file1) was copied to it.
Then, the kernel would generate events for file2, file3 and so on but
never a CREATE event for file1. Isn't that a possibility ? So, what I mean
by that comment is that add a watchpoint soon enough but it could be
possible that by the time the watch is added, a few files might have already
been copied and will not generate events.

> qemu finished processing the old event (especially before you are done
> reading the directory), and if you are hitting that the effect is that
> you see a create event for the new file even though you already have it
> in the tree.
>
> But it is impossible that you miss the creation of the new file (this is
> what I meant with "there is no race").
>
> hope this clarifies,
>   Gerd