WatchService - Exposing more of the Inotify Event Model

[Benedict Elliott Smith]

I was thinking about this very thing on my commute this morning. The
contract of WatchService is necessarily different on different OSes, and I'm
not sure how you could mitigate that, so what you suggest seems reasonable.

I think a satisfactory alternative might be to return what the OS thinks is
the path of the file descriptor (which you currently store), in order to
keep memory requirements low. This would also mitigate the problem that
might occur from getting events for a moved directory, since the
Watchable/Path returned would match the directory's current location.
Without this feature, using events from directories after they have moved
would be quite tricky in fact.

It should probably be documented that some WatchService implementations will
track events for directories after they have moved, and that others do not
though. The PollingWatchService will invalidate a key (as if the directory
were deleted) in this case, and this is (unfortunately) still the default
implementation for us Solaris users.



On 24 September 2010 01:15, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> Benedict Elliott Smith wrote:
>
>> While on the topic of the WatchService API, I wonder if there are any
>> plans to modify the WatchKey to include a method for retrieving the
>> object/path it is watching.
>>
> I've often wondered when this would come up :-)  It was left out because of
> concern that the watch may be on the file (think inode). It may also be
> confusing where you attempt to watch a directory that is already being
> watched, but originally registered with a completely different path. It's
> clearly something that needs to be looked at again, now that the API has
> been used for some time. If WatchKey does get a method to return the
> Watchable then it could only reasonably be specified to returned the
> original Watchable.
>
> -Alan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20100924/3a8088ad/attachment.html