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

Ivan Gerasimov ivan.gerasimov at oracle.com
Fri May 18 21:24:27 UTC 2018

Hi Brian!

On 5/18/18 12:18 PM, Brian Burkhalter wrote:

On May 18, 2018, at 7:42 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

On May 18, 2018, at 7:40 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

The offset in the string comparison is necessary as “C:\pagefile.sys” becomes “pagefile.sys” in fileData.cFileName. I’m not certain that this will work in all cases however but it is certainly no worse than before.

Can the call to wstati64 be removed? That is, if GetFileAttributesExW fails with a sharing violation then just use FindFirstFileW as the fallback. Had not tried that yet but I will. wstati64 branch excised and verified to pass sans and with VS 2017. http://cr.openjdk.java.net/~bpb/8202076/webrev.01/ Is this good to go?

It looks sensible to check the file name after a call to FindFirstFileW, but I have a concern.

What if pathbuf contained an "alternative" name of the directory and/or the file itself (e.g. "C:\Progra~1\file" instead of "C:\Program Files\file")? I guess that FindFirstFileW() may expand the name to normal length (I'm not certain it will really do), so that content of fileData.cFileName will be longer than pathbuf. Then, the call to wcscmp() would read the memory before the start of pathbuf.

In fact, we only need to check that that only file name (without the directory name) is the same, so maybe it will be safer to compare the substrings starting at the very last backslash? If the check fails, then we may want to try to see if pathbuf ends with fileData.cAlternateFileName.

I understand, it might look like too much work for a rare edge case :)

With kind regards, Ivan

Thanks,

Brian

-- With kind regards, Ivan Gerasimov

More information about the core-libs-dev mailing list