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
