JDK-4990650 : REG: File.getCanonicalPath returns incorrect results after a case-only rename
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 1.4.2_04,5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-02-07
  • Updated: 2004-02-20
  • Resolved: 2004-02-20
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
5.0 b40Fixed
Related Reports
Relates :  
Description
description: FULL PRODUCT VERSION :
The bug occurs on:
java version "1.4.2_03"
Java(TM) 2 Runtime Environment, Standard Edition (build
1.4.2_03-b02)
Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)

and

java version "1.5.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build
1.5.0-beta-b32c)
Java HotSpot(TM) Client VM (build 1.5.0-beta-b32c, mixed mode)

It does NOT occur under
java version "1.4.1_05"
Java(TM) 2 Runtime Environment, Standard Edition (build
1.4.1_05-b01)
Java HotSpot(TM) Client VM (build 1.4.1_05-b01, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
File.getCanonicalPath() seems to be caching the result in a way
that
gives incorrect results after the file has been renamed to a
different
case on Windows.

This is happening in 1.4.2_03 and 1.5.0beta, but did not occur
under
1.4.1_05.



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
if there is a file Foo on the disk, the following code shows the
error:

File f = new File("Foo");
System.out.println("before: " + f.getCanonicalPath());
f.renameTo(new File("foo"));
System.out.println("after: " + f.getCanonicalPath());

Or, run the attached program as "java -cp . test.RenameTest Foo
foo".


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
before: c:\test\Foo
after: c:\test\foo
ACTUAL -
before: c:\test\Foo
after: c:\test\Foo

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
package test;

import java.io.File;
import java.io.IOException;

public class RenameTest
{ 
    public static void main(String[] args)
    {
        if (!(args.length == 2))
        {
            System.out.println("must specify from and to
filenames.");
            return;
        }
        
        File f1 = new File(args[0]);
        File f2 = new File(args[1]);

        try
        {
            System.out.println("old canonical: " +
f1.getCanonicalPath());
            System.out.println("old1 canonical: " + new
File(args[0]).getCanonicalPath());
            System.out.println("old2 canonical: " + new
File(args[1]).getCanonicalPath());
            if (!f1.renameTo(f2))
            {
                System.out.println("failed to rename " + args[0] +
" to
" + args[1]);
                return;
            }
            System.out.println("new canonical: " +
f1.getCanonicalPath());
            System.out.println("new1 canonical: " + new
File(args[0]).getCanonicalPath());
            System.out.println("new2 canonical: " + new
File(args[1]).getCanonicalPath());
            
        }
        catch (IOException ioe)
        {
            assert false: ioe;
        }
    }
} 


Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b40 tiger-beta2
14-06-2004

WORK AROUND -Dsun.io.useCanonCaches=false
11-06-2004

EVALUATION This is a bug in java.io.WinNTFileSystem. The intent was to clear out the canonicalization caches upon rename or deletion operations; this is done correctly in Win32FileSystem. WinNTFileSystem overrides the wrong methods from Win32FileSystem, causing the canonicalization cache cleanup to be skipped. ###@###.### 2004-02-10 Fixed in 1.5.0 b40. ###@###.### 2004-02-13
10-02-2004