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

[Jaikiran Pai]

On 17/03/21 1:26 pm, Alan Bateman wrote:
> On 17/03/2021 03:21, Jaikiran Pai wrote:
>> :
>>
>>
>> The code tries to read from NUL: on a Windows setup. This code runs 
>> into the following exception on Windows when the 
>> java.io.File#toPath() gets invoked:
>>
>>
>> Exception in thread "main" java.nio.file.InvalidPathException: 
>> Illegal char <:> at index 3: NUL:
>>     at 
>> java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
>>     at 
>> java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
>>     at 
>> java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
>>     at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
>>     at 
>> java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230)
>>     at java.base/java.io.File.toPath(File.java:2316)
>>     at FileTest.main(FileTest.java:18)
>>
>>
>> So it looks like java.io.File.toPath() on Windows isn't able to 
>> recognize the null device construct?
>
> Special devices, esp. those historical devices from the DOS era, are 
> very problematic.
>
> NUL is somewhat benign compared to the other and you use "NUL" (not 
> "NUL:") then should work as you expect. 

Thank you David and Alan.

I can confirm that using "NUL" or "nul" work fine in the above code, 
with the FileInputStream/FileOutputStream constructors as well as 
Files.newInputStream(f.toPath()) and Files.newOutputStream(f.toPath()).


> Changing the path parser to allow ":" in places other than after drive 
> letters is a slippery slope as it brings all a lot of the issues that 
> plagued the older code.

Understood.


-Jaikiran