Wolfgang Baltes wolfgang.baltes at
Tue Jan 11 14:41:54 PST 2011

On 2011-01-11 04:12, Alan Bateman wrote:
> So I've been looking further at the issue that you originally reported 
> and I'm wondering if you've only tried to delete the file tree with 
> something other than Windows Explorer. I suspect the issue is that 
> Windows Explorer is trying to move the directories into the Trash 
> directory and it's getting a sharing violation (because Windows 
> doesn't allow you to delete a directory if it contains a sub-directory 
> that is being watched).
> -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. 
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 inserted these code lines behind line 256 (creation of file2):

         final Path subsubdir = subdir.resolve(Paths.get("subsubdir"));
         final Path file3 = subsubdir.resolve(Paths.get("file3.txt"));
         final Path file4 = subsubdir.resolve(Paths.get("file4.txt"));

These lines create an additional subdirectory and two files in it. The 
same experiment then sometimes gives:

     Scanning C:\watchtest ...
     register: C:\watchtest
     register: C:\watchtest\subdir
     register: C:\watchtest\subdir\subsubdir
     Done with registering directories.
     ENTRY_DELETE: C:\watchtest\subdir\file1.txt
     ENTRY_MODIFY: C:\watchtest\subdir
     ENTRY_DELETE: C:\watchtest\subdir\subsubdir\file3.txt
     Removing watch key for C:\watchtest\subdir\subsubdir.
     ENTRY_DELETE: C:\watchtest\subdir\file2.txt
     ENTRY_MODIFY: C:\watchtest\subdir\SUBSUB~1
     ENTRY_DELETE: C:\watchtest\subdir\subsubdir

and sometimes:

     Scanning S:\watchtest ...
     register: S:\watchtest
     register: S:\watchtest\subdir
     register: S:\watchtest\subdir\subsubdir
     Done with registering directories.
     ENTRY_DELETE: S:\watchtest\subdir\file1.txt
     ENTRY_DELETE: S:\watchtest\subdir\file2.txt
     ENTRY_MODIFY: S:\watchtest\subdir\SUBSUB~1
     ENTRY_DELETE: S:\watchtest\subdir\subsubdir
     S:\watchtest\subdir\subsubdir does not exist... ... and key is 
     ENTRY_MODIFY: S:\watchtest\subdir
     ENTRY_DELETE: S:\watchtest\subdir\subsubdir\file3.txt
     Removing watch key for S:\watchtest\subdir\subsubdir.

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.
- 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?
- The order of the events may be different due to each directory 
reporting through a different thread?

I hope this helps,

More information about the nio-dev mailing list