WatchService

[Alan Bateman]

Wolfgang Baltes wrote:
> My comments in item 4 were not specific to the NIO2 API, but are more 
> general. For example, if somebody writes some code where he would 
> return an empty array, then he has to define this array. If you write 
> a collection of packages, you end up defining this array again and 
> again (unless you have some "core" package). The idea here is to offer 
> this feature in the base library, so that others don't have to create 
> it. It may not be used in the NIO2 library itself. Of the NIO2 classes 
> I have worked with, Path is the only one where this is likely to be of 
> some help. The other class would be WatchKey, but this is more likely 
> to be used in collections, for which there are already "empty" versions.
>
> However, related to item 5 below, instead of returning null from 
> getRoot and getParent, one could return the EMPTY_PATH path (= Path 
> with zero elements; but not root), which could then be used in a 
> normal execution path, when null would require special code. But then, 
> I am not sure this is even possible with the current implementation as 
> the root component "/" already has some characteristics of an empty 
> path (zero length and null name) and this may already be exploited by 
> your code, and it does not have a neutral behavior in most methods.
I don't think we have any assumptions in the code and a root directory 
("/" or "C:\" or "\\server\share" for example) is just considered a 
path. The issue with an empty path is that there would be one per 
provider and it would create a couple of anomalies in API that would 
have to be worked out. However, it is worth going through again.

> Yes! For example, the Javadoc for the WatchService says that "When an 
> event is reported to indicate that a file in a watched directory has 
> been modified then there is no guarantee that the program (or 
> programs) that have modified the file have completed." However, there 
> is no hint what to look for as an indicator to assure/wait for 
> completion. 
The next statement is "Care should be taken to coordinate access with 
other programs that may be updating the file" and it gives a suggestion 
to use file locking. Another suggestion that we could include is to 
atomically move files into place. Ideally we would have an event like 
CLOSE_AFTER_MODIFY (or something like that) but that isn't implementable 
by polling or isn't something that is widely supported by the native 
event notification mechanisms either.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110111/3a529493/attachment.html