JDK-4895132 : problems with filename cache on Windows
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 1.4.2
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2003-07-23
  • Updated: 2003-10-06
  • Resolved: 2003-08-30
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.
Other
1.4.2_02 02Fixed
Related Reports
Relates :  
Description
1. sun.io.useCanonPrefixCache cannot be disabled.

    private static boolean getBooleanProperty(String prop, boolean defaultVal) {
        String val = System.getProperty("sun.io.useCanonCaches");

  "sun.io.useCanonCaches" should be prop

2. For an existing file, getCanonicalPath() sometimes can produce
a pathname whose case doesn't match that of the existing file's pathname.
This doesn't matter in terms of being able to access the file, but it appears
that some applications, such as TomCat, depend on getting the correct case.
Sometimes the answer for the same input is inconsistent. Here's the
test program from the customer.

import java.io.*;

public class Test {

    public static void main(String args[]) {
        
        File test = null;
        test = new File("foo/Test.txt");
        try {
            System.out.println("Can path: " + test.getCanonicalPath())
;
        } catch (Exception e) {
            e.printStackTrace();
        }
        
        test = new File("foo/test.Txt");
        try {
            System.out.println("Can path: " + test.getCanonicalPath())
;
        } catch (Exception e) {
            e.printStackTrace();
        }
        test = new File("foo/Test.Txt");
        try {
            System.out.println("Can path: " + test.getCanonicalPath())
;
        } catch (Exception e) {
            e.printStackTrace();
        }
        
    }

}

touch foo\test.txt
rm -f foo\Test.txt

On 1.4.2, this produces
c:\foo\test.txt
c:\foo\test.txt
c:\foo\Test.txt

With the cache disabled, it produces
c:\foo\test.txt
c:\foo\test.txt
c:\foo\test.txt

It is strange that #1 and #3 are different when the cache is enabled.

rm -f foo\test.txt
touch foo\Test.txt

1.4.2 with cache enabled produces:
c:\foo\Test.txt
c:\foo\test.txt
c:\foo\Test.txt

Cache disabled:
c:\foo\Test.txt
c:\foo\Test.txt
c:\foo\Test.txt

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_02 tiger FIXED IN: 1.4.2_02 tiger INTEGRATED IN: 1.4.2_02 tiger tiger-b18 VERIFIED IN: 1.4.2_02
14-06-2004

EVALUATION The first problem has been solved by the fix for 4846976. Looks like the second problem may have been introduced by the cache work in 1.4.2. ###@###.### 2003-07-23 The problem of canonicalization returning differently-capitalized file names than on disk on the Windows platform is a side effect of the prefix cache that was introduced in 1.4.2 for performance reasons (specifically startup time). It seems clear that we can't completely avoid touching the disk, but we can touch it only once per hit in the prefix cache instead of the multiple times a full canonicalization requires. This has been implemented and fixes the problem. ###@###.### 2003-08-22
22-08-2003

WORK AROUND Specify -Dsun.io.useCanonCaches=false to the JVM. ###@###.### 2003-07-23
23-07-2003