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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
