JDK-8189953 : FileHandler constructor throws NoSuchFileException with absolute path
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.logging
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86_64
  • Submitted: 2017-10-24
  • Updated: 2017-11-16
  • Resolved: 2017-11-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10
10 b32Fixed
Related Reports
Relates :  
JDK-8153250 - java.io.File does not handle Windows paths of the form "D:" (no path) correctly
Relates :  
JDK-8189862 - java.io.File constructor File(File, String) creates wrong path on Windows JDK9
Relates :  
JDK-8130462 - File.isAbsolute() does not cover all cases
Description
FULL PRODUCT VERSION :
Java(TM) SE Runtime Environment (build 9+181)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 10.0.15063]

A DESCRIPTION OF THE PROBLEM :
package test;

import java.io.IOException;
import java.util.logging.FileHandler;
import java.util.logging.Handler;

public class Test {

    public static void main(String[] args) {
        try {
            Handler handler = new FileHandler("c:/Workspace/hoge.log");

        } catch (SecurityException | IOException e) {
            e.printStackTrace();
        }
    }
}

throws

java.nio.file.NoSuchFileException: c:Workspace\hoge.log.lck
	at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:85)
	at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
	at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
	at java.base/sun.nio.fs.WindowsFileSystemProvider.newFileChannel(WindowsFileSystemProvider.java:116)
	at java.base/java.nio.channels.FileChannel.open(FileChannel.java:292)
	at java.base/java.nio.channels.FileChannel.open(FileChannel.java:340)
	at java.logging/java.util.logging.FileHandler.openFiles(FileHandler.java:511)
	at java.logging/java.util.logging.FileHandler.<init>(FileHandler.java:307)
	at test.Test.main(Test.java:11)



REPRODUCIBILITY :
This bug can be reproduced always.
Comments
Webrev sent for review: http://cr.openjdk.java.net/~dfuchs/webrev_8189953/webrev.00/
02-11-2017
I suspect changing the algorithm in FileHandler::generate to use Path rather than File would solve the issue, especially if we add something at the end to resolve the result against a possible root obtained from Paths.get(pattern).getRoot() (when that is not null).
31-10-2017
new File(new File(���c:���), ���Workspace���) should yield "c:Workspace". Older versions of the JDK 8 behaved differently so this may indeed explain what it worked by accident in past releases.
31-10-2017
The problem might be in FileHandler::generate. The algorithm will construct a File and then call toString(). For an input of the form "c:/Workspace/hoge.log", then the constructed file will look like this: new File(new File(new File(���c:���), ���Workspace���), ���hoge.log���).toString(); which I expect now returns "c:Workspace\\hoge.log" on Windows. This code doesn't seem to have changed between 8 and 9, so it probably means that for this to be a regression, something has changed in the underlying implementation of File (maybe in the underlying WindowsFileSystem?). It is not completely clear to me where this bug should be fixed: it may be right for new File(new File("c:"), "foo").toString() to return "c:foo" rather than "c:\\foo" - but then that would mean that FileHandler::generate would need to embed some windows specific code - which is disturbing.
31-10-2017
To reproduce the issue, run the attached test case. When passing String "c:\\temp\\TestFile.log", the test case passes in both JDK 8u151 and JDK 9, but when using String "c:/temp/TestFile.log" , the test case passes only in JDK 8u151 and fails in JDK 9 with the exception as shown below. JDK 8u151 - Pass JDK9 +181- Fail On JDK 8u151, the test case runs successfully. Output on JDK 9: java.nio.file.NoSuchFileException: c:temp\TestFile.log.lck at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:85) at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103) at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108) at java.base/sun.nio.fs.WindowsFileSystemProvider.newFileChannel(WindowsFileSystemProvider.java:116) at java.base/java.nio.channels.FileChannel.open(FileChannel.java:292) at java.base/java.nio.channels.FileChannel.open(FileChannel.java:340) at java.logging/java.util.logging.FileHandler.openFiles(FileHandler.java:511) at java.logging/java.util.logging.FileHandler.<init>(FileHandler.java:307) at JI9051303.main(JI9051303.java:9)
25-10-2017