Files.isWritable and SUBST drives on Windows 7

[Alan Bateman]

On 09/02/2014 20:49, David Polock wrote:
> :
>
> For a substituted drive, the function calculates a directory 
> (y:\temp). This root is then used to call "GetVolumeInformation", 
> which fails for the directory name. The windows exception is caught 
> and the result of the call sequence is "not writable".

Thanks for the bug report, I've created JDK-8034057 to track it. As you 
noted, we use GetVolumePathName to get the mount point but it appears 
that additional probing (maybe QueryDosDevice) is required to deal with 
SUBST'ed drives.

As to why isWritable is impacted then it's because isWritable uses 
FileStore to determine if the volume is read-only or not (the other 
isXXX don't need to do this). It's unfortunate that it runs into this issue.


>
> I don't know whether Windows 7 is buggy, or the call sequence is not 
> allowed, but the effect is a writable directory, that is reported as 
> read-only.
Just one small correction here. When isWritable returns false then it 
does not mean that the file is read-only. Instead the return value is 
specified as:

"true if the file exists and is writable; false if the file does not 
exist, write access would be denied because the Java virtual machine has 
insufficient privileges, or access cannot be determined"

In order to get exception information then it requires using the 
provider-level checkAccess method.

I don't know how your library is using isWritable but if the file is 
opened immediately after checking that it is writable then it might be 
best to drop the isWritable check. This would avoid race conditions 
(file being replaced or changing permissions) and would likely be a bit 
faster too.

-Alan.