8202076: test/jdk/java/io/File/WinSpecialFiles.java on windows with VS2017

[Ivan Gerasimov]

Thank you Brian, this looks good to me.

I assume it compiles Okay, though according to MSDN wcsrchr() and 
wcscmp() require either <string.h> or <wchar.h> to be included (must 
have been added through one of already included header).

No need for another webrev if you decide to add one of these.

With kind regards,

Ivan


On 5/21/18 5:43 PM, Brian Burkhalter wrote:
> Updated webrev: http://cr.openjdk.java.net/~bpb/8202076/webrev.03/ 
> <http://cr.openjdk.java.net/%7Ebpb/8202076/webrev.03/>
>
> On May 18, 2018, at 4:49 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com 
> <mailto:ivan.gerasimov at oracle.com>> wrote:
>
>> I minor suggestion is that I would recommend to use L'\\' to 
>> explicitly indicate it is a wide char literal.
>
> Changed as suggested.
>
>> And the last comment:  Maybe it makes sense to update the test 
>> java/io/File/WinSpecialFiles.java to make sure we deal correctly with 
>> wildcards in a file name (and that nobody will accidentally optimize 
>> away the check of the filename).
>
> I did not make any changes in this direction at this time.
>
> On May 18, 2018, at 11:20 PM, Alan Bateman <Alan.Bateman at oracle.com 
> <mailto:Alan.Bateman at oracle.com>> wrote:
>
>> GetFileAttributesEx follows sym links, FindFirstFile does not. You 
>> should be able to quickly check it but I think the patch means that 
>> it will return the size of the link file when it linked to an lock 
>> file. Assuming I have this right, then you'll need to look at the 
>> dwFileAttributes field in the WIN32_FIND_DATAW structure and return 0 
>> when the attribute to indicate a reparse point is set.
>
> Fixed.
>
> Successfully re-tested using VS 2017 and the continuous integration 
> system.
>
> Thanks,
>
> Brian

-- 
With kind regards,
Ivan Gerasimov