Review request: JDK-8014394 (fs) WatchService failing when watching \\server\$d

[Alexey Utkin]

Hi Alan,

The era of 32 is over in Apple world. Seems that is the time switching 
to x64 everywhere. "640K ought to be enough for anybody ".  The problem 
is in program up-time.  If we are discussing about GUI application, 
0xFFFFFFFF is infinity. But from a service point of view it is not so 
clear. (Webkit source-save server is a good example, but, yes, it isn't 
on Windows.)

I rollback the changes in WindowsWatchService to avoid the blot.

Regards,
-uta



On 5/22/2013 11:58 PM, Alan Bateman wrote:
> On 22/05/2013 17:07, Alexey Utkin wrote:
>>  Bug description:
>> https://jbs.oracle.com/bugs/browse/JDK-8014394
>> http://bugs.sun.com/view_bug.do?bug_id=8014394
>>
>> Here is the suggested fix:
>> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8014394/webrev.00/
>>
>> Summary:
>> The problem source is the ERROR_MORE_DATA warning event that was 
>> treated as error.
>> The suggested fix contains limited refactoring that can be critical 
>> for further support.
>>
>> :
> Thanks for finding the ERROR_MORE_DATA case, that was missed in the 
> original implementation and I can only assume just hasn't been noticed 
> (maybe because watching a directory over CIFS wouldn't be as common as 
> local).
>
> On expanding on the width of the completion key then this this 
> increases the footprint of the key to WatchKey map which doesn't seem 
> necessary (we originally choose an int as it should be more than 
> enough for extreme usage over an extended period). Maybe it would be 
> better to keep the WindowsNativeDispatcher.* changes to use jlong/ 
> ULONG_PTR but revert the usage in WindowsWatchService to avoid the blot.
>
> -Alan.