-
Bug
-
Resolution: Unresolved
-
P3
-
24, 25
ADDITIONAL SYSTEM INFORMATION :
OS: Windows 11 Pro
Locale: Japanese
JDK: OpenJDK 24.0.1 and 24
A DESCRIPTION OF THE PROBLEM :
This method is implementation-dependent, so this may not strictly qualify as a bug. However, I'm reporting it because it seems to be an unintended behavioral change.
Starting with Java 24, on Windows, when passing the path of a file mounted on a network drive (e.g., Z:\a.txt) to File.getCanonicalPath, the path is now automatically resolved to its UNC form (e.g., \\192.168.1.3\...).
UNC paths cannot be used as working directories when launching external processes on Windows (e.g., via Runtime.exec). As a result, this change breaks some existing code that worked correctly in previous Java versions.
While this behavior can be avoided by using the more modern Path.toRealPath instead of File.getCanonicalPath -- which does not expand to UNC paths -- it cannot be avoided in APIs that likely rely internally on File.getCanonicalPath, such as JFileChooser.setDirectory in Swing.
Overall, I believe it would be better for compatibility with existing code if this behavioral change in File.getCanonicalPath were reverted or adjusted.
REGRESSION : Last worked in version 23
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. On Windows, mount a network location as a network drive (e.g., Z:\).
2. Create a File instance pointing to a file or folder on the network drive (e.g., Z:\a.txt).
3-A. Call getCanonicalPath() on the instance and observe the resulting path.
3-B. Alternatively, pass the network drive path to JFileChooser#setDirectory, select a file within the directory, and observe the returned path.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The path on the network drive is returned (e.g., Z:\a.txt).
ACTUAL -
The UNC path is returned instead (e.g., \\192.168.1.3\share-directory\a.txt).
---------- BEGIN SOURCE ----------
import java.io.File;
import java.io.IOException;
public class ReportExample {
public static void main(String[] args) throws IOException {
// When the network drive "Z:" is mounted,
// and "a.txt" exists on that drive,
// create a File instance pointing to it.
java.io.File file = new File("Z:\\a.txt");
// Use the target method to retrieve the path.
String path = file.getCanonicalPath();
// Print the result.
System.out.println("Retrived path: " + path);
// Java 24 (if a.txt exists): \\192.168.1.3\share-directory\a.txt
// Java 24 (if a.txt does NOT exist): Z:\a.txt
// Java 23: Z:\a.txt
}
}
---------- END SOURCE ----------
OS: Windows 11 Pro
Locale: Japanese
JDK: OpenJDK 24.0.1 and 24
A DESCRIPTION OF THE PROBLEM :
This method is implementation-dependent, so this may not strictly qualify as a bug. However, I'm reporting it because it seems to be an unintended behavioral change.
Starting with Java 24, on Windows, when passing the path of a file mounted on a network drive (e.g., Z:\a.txt) to File.getCanonicalPath, the path is now automatically resolved to its UNC form (e.g., \\192.168.1.3\...).
UNC paths cannot be used as working directories when launching external processes on Windows (e.g., via Runtime.exec). As a result, this change breaks some existing code that worked correctly in previous Java versions.
While this behavior can be avoided by using the more modern Path.toRealPath instead of File.getCanonicalPath -- which does not expand to UNC paths -- it cannot be avoided in APIs that likely rely internally on File.getCanonicalPath, such as JFileChooser.setDirectory in Swing.
Overall, I believe it would be better for compatibility with existing code if this behavioral change in File.getCanonicalPath were reverted or adjusted.
REGRESSION : Last worked in version 23
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. On Windows, mount a network location as a network drive (e.g., Z:\).
2. Create a File instance pointing to a file or folder on the network drive (e.g., Z:\a.txt).
3-A. Call getCanonicalPath() on the instance and observe the resulting path.
3-B. Alternatively, pass the network drive path to JFileChooser#setDirectory, select a file within the directory, and observe the returned path.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The path on the network drive is returned (e.g., Z:\a.txt).
ACTUAL -
The UNC path is returned instead (e.g., \\192.168.1.3\share-directory\a.txt).
---------- BEGIN SOURCE ----------
import java.io.File;
import java.io.IOException;
public class ReportExample {
public static void main(String[] args) throws IOException {
// When the network drive "Z:" is mounted,
// and "a.txt" exists on that drive,
// create a File instance pointing to it.
java.io.File file = new File("Z:\\a.txt");
// Use the target method to retrieve the path.
String path = file.getCanonicalPath();
// Print the result.
System.out.println("Retrived path: " + path);
// Java 24 (if a.txt exists): \\192.168.1.3\share-directory\a.txt
// Java 24 (if a.txt does NOT exist): Z:\a.txt
// Java 23: Z:\a.txt
}
}
---------- END SOURCE ----------
- caused by
-
JDK-8003887 File.getCanonicalFile() does not resolve symlinks on MS Windows
-
- Resolved
-