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

[Jaikiran Pai]

On 17/03/21 3:10 pm, Jaikiran Pai wrote:
> 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.
>
FWIW - that bug report states that they ran into this even when using 
"nul" and not just "nul:". So there might be something more going on 
here and am just waiting to see if they can provide us a build file to 
reproduce this issue.


-Jaikiran