8202076: test/jdk/java/io/File/WinSpecialFiles.java on windows with VS2017 (original) (raw)

Ivan Gerasimov ivan.gerasimov at oracle.com
Tue May 22 05:51:21 UTC 2018

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 WIN32FINDDATAW 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

More information about the core-libs-dev mailing list