WatchService

[Alan Bateman]

Wolfgang Baltes wrote:
>
> Alan,
>
> I have run the same code as sent before and repeated step 3, now using 
> the Windows Command Prompt instead of Windows Explorer. The bottom 
> line result is that the deletion of the directory is now reported 
> correctly. 
Thanks for checking this. When you use rmdir then it really deletes the 
directory and so the corresponding watch key will be automatically 
canceled and queued so that you know that it is no longer watched. I 
think Windows Explorer doesn't actually attempt a delete but instead 
attempts to move the directory into the "Recycle Bin" directory. My 
guess is that it gets a sharing violation because we have an open handle 
to the directory and then falls back to a deferred/delayed move - this 
is just a guess but it would explain why we don't get the event.


> But read on to see some of the details. To reproduce:
>
> - Open a Windows Command Prompt window.
> - Make c:\watchtest the current directory.
> - Execute "rmdir /s /q subdir".
>
> The console output is:
>     Scanning C:\watchtest ...
>     register: C:\watchtest
>     register: C:\watchtest\subdir
>     Done with registering directories.
>     ENTRY_DELETE: C:\watchtest\subdir\file1.txt
>     ENTRY_DELETE: C:\watchtest\subdir\file2.txt
>     Removing watch key for C:\watchtest\subdir.
>     ENTRY_MODIFY: C:\watchtest\subdir
>     ENTRY_DELETE: C:\watchtest\subdir
>
> In this case everything works as expected, because this command 
> iterates from the bottom of the file tree up. Running this example 
> multiple times, I observe that sometimes one of the file deletions 
> (mostly file2.txt) is not reported, probably due to the fact that the 
> watch key was canceled!?
I don't think we can do anything about this. When you delete a watched 
directory on Windows then you will sometimes get events to indicate that 
the entries in the directory were deleted, sometimes you don't. There's 
lot of wriggle room in the WatchService spec to cover us for these 
implementation specific differences.

>
> :
>
> There are several observations to be made:
> - The rmdir command iterates from the bottom of the tree up.
> - Sometimes, the deletion of file3 is reported after its directory 
> subsubdir is effectively deleted.
> - Most of the time, the deletion of file4 is not reported, probably 
> because the watch key is canceled.
> - The parent of the watched directory subsubdir is not deleted 
> (directory subdir remains after the code has finished). This is the 
> bug you mentioned in an earlier message.
Yes, it's because there is an open handle to each directory that you 
register with the WatchService. It doesn't prevent the directory from 
being deleted but we need the notification to trigger the closing of the 
handle and so there is a tiny window where it is possible to delete the 
parent directory after deleting the sub-directory. We have in the bug 
database but I don't think we can do anything about it.

One thing I should have mentioned before is that our Windows 
WatchService implementation supports an implementation specific modifier 
that allows you to monitor a file tree with a single registration. If 
you want to try it out do this:

 register(watcher,
             new WatchEvent.Kind<?>[]{ ENTRY_DELETE },
             com.sun.nio.file.ExtendedWatchEventModifier.FILE_TREE);

With this modifier then you only register the top directory and the 
context for each event is the relative path from the top directory. It's 
not a portable solution and only works on Windows but it would be 
interesting to how it compares.

> - For ENTRY_MODIFY, the 8.3 form of the directory name is used instead 
> of the long form. Of all the tests done so far, this is the first 
> where a name is long enough for this to happen. => This prompts me to 
> wonder whether there is a method in Path that allows to get the long 
> form, given the 8.3 form, and conversely the 8.3 form given the long 
> form?
That is a good point as our implementation does not convert events for 
8.3 names into long names (which might be problematic with delete 
events). I'm curious how you generated these events. Were you in CMD or 
COMMAND or maybe you monitored the file using the 8.3 form explicitly?


> - The order of the events may be different due to each directory 
> reporting through a different thread?
The implementation preserves the order of the create and delete events 
that we get the events from Windows.

-Alan.