WatchService questions

[Alan Bateman]

Sebastian Sickelmann wrote:
> :
> While reviewing 6907760 i think i found one problem why John is facing so many Events.
>
> If the Copy of the many files is not done in one Thread (ex. multiple Applications writing to the same directory), AbstractWatchKey will only increase modification count if the context that is changing is the same as the last added to the events-lists.
>
> If i am right, the order of the events is not guaranteed. So AbstractWatchKey could check the whole events-list and increase the modification count. This can only be done if we can find a quick implementation. I got some ideas but not tried it yet.
>
> I add a Testcase that shows the Problem with multiple Threads. You can change SEQUENCIAL to true to see how it works in an non-threaded Environment.
>
> Kind regards
> Sebastian
>   
The watch service implementations that makes use of kernel support 
always process and queues the events in the order that they are 
received. The polling implementation (used when there isn't kernel 
support) processes snapshots of the directory and so cannot infer the 
order of changes between snapshots. It's okay for several entities 
(maybe threads in the same VM, maybe other programs or processes) to be 
creating or changing files at the same time. It does reduce the 
likelihood of repeated modification events to the same file and so the 
representation will be less efficient. You can't re-order create or 
delete events as otherwise the application's view of the directory will 
get out of sync. It may be useful in some cases to know when a file was 
modified relative to other operations - I think you are proposing to not 
do this, is that right? I looked at the test you attached but it doesn't 
seem to demonstrate a problem (or at least I don't see it on the first 
glance).

-Alan.