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

[Ivan Gerasimov]

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