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

[Jaikiran Pai]

Hello Alan,

On 17/03/21 2:45 pm, Alan Bateman wrote:
> On 17/03/2021 08:21, Jaikiran Pai wrote:
>> :
>>
>> I can confirm that using "NUL" or "nul" work fine in the above code,
>
> I don't know the context for your question 

A while back Apache Ant switched to using the 
Files.newInputStream/Files.newOutputStream construct as a replacement 
for the FileInputStream and FileOutputStream constructors[1]. That 
commit seems to have introduced an regression in Ant as noted here[2]. 
It appears that users of Ant were using "nul" (and even "nul:") as 
destination file to have Ant write the data to that destination. 
Internally Ant constructs an instance of java.io.File from the user 
provided path string ("nul" or "nul:" in this case) and constructs a 
OutputStream out of it. Previously (before we made that commit in Ant), 
it would be using the FileOutputStream constructor (and would succeed) 
and now it uses the Files.newOuputStream(...) which expects a Path 
instance and this where our usage of java.io.File.toPath() ran into the 
issue I note in this mail, when I started investigating this.

I didn't mention this context in my mail because the error noted in 
those user reports is surprisingly a bit different than what I have seen 
in my experiments on Windows and I don't think I have so far narrowed it 
down to a JDK issue (if any). In their case, it appears the call went 
past the issue we are discussing this mail and instead failed later with 
something like:

java.nio.file.FileSystemException: E:\nul: Incorrect function.
         at 
sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
         at 
sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
         at 
sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
         at 
sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:230)
         at 
java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:434)
         at java.nio.file.Files.newOutputStream(Files.java:216)


I'm not yet sure how they managed to get to that stage and am waiting to 
see if they can provide us with a reproducible build file to reproduce this.


> but just to mention InputStream.nullInputStream() or 
> Reader.nullReader() may be useful if you have something that wants to 
> read from a null stream.

We have had a recent discussion in Ant dev mailing list[3] to introduce 
such a construct in some of our Ant tasks where users can tell us that 
they want the output/error output discarded (that's what they are using 
/dev/null and "nul:" for). That will prevent all these platform specific 
usages of null device representations. Internally, in the 
implementation, we will use the APIs like the one you note and avoid 
having to deal with null devices.


[1] 
https://github.com/apache/ant/commit/af74d1f6b882cef5f4167d972638ad886d12d58c

[2] https://bz.apache.org/bugzilla/show_bug.cgi?id=62330

[3] https://www.mail-archive.com/dev@ant.apache.org/msg48730.html


-Jaikiran