WatchService - Exposing more of the Inotify Event Model

fm fudmail at gmail.com
Thu Sep 2 10:59:54 PDT 2010


Thank you for the response. This is the type of info I was looking
for. Reading the WatchService related API documentation I got the
sense it was designed for extension. After skimming over some of the
related source code, it wasn't yet clear to me the best way to go
about accessing the additional Linux specific filesystem events. After
looking at the JDK7 source code it was clear to me a lot of hard work
went into the design of the WatchService notification capability and
it would be a shame not to be able to leverage it for accessing
additional event tyeps.  I will look into you suggestions.

I am also aware that Inotify's IN_CLOSE_WRITE event is not the silver
bullet to my particular project--but as the link Rémi provided points
out, it may be more suitable that IN_MODIFY (in my case as well as
others). But I believe you are correct also that one cannot assume
something else does not have a file open for writing...it is just much
more unlikely in my particular case.

Regards


On Thu, Sep 2, 2010 at 8:00 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> f m wrote:
>>
>> Per Alan B.'s request, I'm moving a discussion here that was started at
>> http://forums.java.net/jive/thread.jspa?threadID=152825&tstart=0
>> <http://forums.java.net/jive/thread.jspa?threadID=152825&tstart=0>
>>
>> I'll try to summarize.
>>
>> A useful goal of the JDK7 WatchService is to provide a uniform file system
>> event facility across multiple operating systems. However, in some cases, it
>> may be more desirable to give up the portability in order to tap into the
>> full expressiveness of the event model of the native OS. For example,
>> Inotify on the Linux platform provides additional events not currently used
>> by the LinuxWatchService implementation such as: IN_ACCESS, IN_CLOSE_WRITE,
>> IN_CLOSE_NO_WRITE, and IN_OPEN.
>>
>> I gave one example at the above URI where an event like IN_CLOSE_WRITE
>> could be used to detect and process a large file only after it has been
>> completely copied into a watch directory.
>>
>> After looking over the internal LinuxWatchService.java source code, it
>> appears that the implementation could be readily used (modified or resused?)
>> to also provide access to these additional event types. Another event class
>> representation like LinuxWatchEventKinds would need to be added and used
>> alternatively to the StandardWatchEventKinds.
>>
>> My question. Would extending the LinuxWatchService capability to
>> optionally expose the greater set of Inotify event types be in scope for JDK
>> 7 development, or will client developers who desire this capability need to
>> find 3rd party implementations (or develop it themselves)?
>>
>> Regards.
>>
> The API is designed to allow for events and modifiers that are defined
> beyond the javadoc so provider implementations can include support for other
> events if they wish. We haven't included any support for other events in the
> JDK because our primary motive has been to help the performance of
> applications that are forced to poll the file system today. If you are
> looking for pointers then there is one implementation specific modifier
> (com.nio.file.ExtendedWatchEvent)  that might help show you how additional
> support is included. You are welcome to hack on the code and try out
> additional events but you have to be a contributer to contribute patches
> [1].  A small comment on the "close after write" event is that I don't think
> you are guaranteed that the file isn't being modified by other entities.
> That might not be a concern in your environment but just mentioning it.
>
> -Alan.
>
> [1] http://openjdk.java.net/contribute/
>


More information about the nio-dev mailing list