java.io.File#toPath() on Windows doesn't understand "NUL:" (null device)?

[Jaikiran Pai]

On 22/03/21 2:36 pm, Alan Bateman wrote:
> On 20/03/2021 07:16, Jaikiran Pai wrote:
>> :
>>
>> I received some inputs on that Ant bugzilla issue. Based on that, I 
>> was able to reproduce the exception and IMO it's a bug in 
>> Files.newOutputStream() API. I have opened 
>> https://bugs.openjdk.java.net/browse/JDK-8263898 with the relevant 
>> details. I considered this a bug and took the liberty of opening that 
>> JBS issue because as I note in that issue, this only happens 
>> specifically when TRUNCATE_EXISTING (default) option gets used 
>> against "nul" on Windows.
>
> OutputStream.nullOutputStream() may be a better and more portable 
> alternative. In general, the DOS era reserved names (including NUL) 
> are very under specified and many file operations lead to surprising 
> behavior (this isn't solely a JDK issue, I think other runtimes and 
> languages also get tripped up). In this case, the attempt to truncate 
> the file to zero length is failing. Sure, it can be be worked around 
> but workarounds like this tend to cause issues in other unusual cases 
> so care is required.


Understood. Thank you Alan for those inputs. Just yesterday, Stefan (one 
of the Ant developers) has implemented a way where we allow users to 
discard output without relying on null devices. It uses the approach 
that you note (although we use an internal NullOutputStream, since we 
want Ant to be usable in Java 8 where OutputStream.nullOutputStream() 
isn't present). We will be asking our users to move to this new 
way/attribute instead of relying on null devices.

-Jaikiran