File.createTempFile seems to be broken in JDK 1.6.0_11

Question

Hi!
Can anyone confirm please?
On (German) Windows XP systems, since JDK 1.6.0_11, there seems to be a serious bug in the implementation of File.createTempFile: After having created such a temp file, using getPath() or getAbsolutePath() may show a broken path, with abbreviated path components.
Here is an example result path (broken):
"C:\DOKUME~1\schneid\LOKALE~1\Temp\temp_file6617344501941011051.tmp"
As you can see, the directory "DOKUMENTE_UND_EINSTELLUNGEN" (German version of Windows XP) is abbreviated to "DOKUME~1".
I have attached an executable Java class that shows the problem.
If someone confirms, then I will post an issue.
Best,
Michael
======= BEGIN CLASS "CreateTempFileBug" ================
import java.io.File;
* Bug: Broken path for File.createTempFile
* Description:
* File.createTempFile() creates a file object with a broken getPath() string.
* The path string contains "~", i.e. the path elements are abbreviated.
* Same problem for getAbsolutePath(). Valid paths only for getCanonicalPath().
* Example-Output:
* "C:\DOKUME~1\schneid\LOKALE~1\Temp\temp_file6617344501941011051.tmp"
* System:
* OS: WinXP / German
* JRE: 1.6.0_11
* Since:
* I think this is new to patch level 11 of Java 6. It breaks my software,
* but in earlier versions everything was fine.
* @author Michael Schneider ([email protected])
public class CreateTempFileBug {
     public static void main(String[] args) throws Exception {
          // Creating a temporary file, and printing the path.
          // RESULT: broken path (having abbreviated path elements)
          // for getPath and getAbsolutePath, but ok for getCanoncialPath
          File tempFile = File.createTempFile("temp_file", null);
          System.out.println("temp file / getPath: BROKEN: <" + tempFile.getPath() + ">");
          System.out.println("temp file / getAbsolutePath: BROKEN: <" + tempFile.getAbsolutePath() + ">");
          System.out.println("temp file / getCanonicalPath: OK: <" + tempFile.getCanonicalPath() + ">");
          // For comparison, creating a normal file in the working dir
          // and printing the absolute path.
          // RESULT: valid paths (at least on my system)
          File normalFile = new File("normal_file");
          System.out.println("normal file / getPath: OK: <" + normalFile.getPath() + ">");
          System.out.println("normal file / getAbsolutePath: OK: <" + normalFile.getAbsolutePath() + ">");
          System.out.println("normal file / getCanonicalPath: OK: <" + normalFile.getCanonicalPath() + ">");
===== END CLASS =====================================
Edited by: m_schnei on Feb 13, 2009 11:17 PM
Edited by: m_schnei on Feb 13, 2009 11:20 PM

Answer 1

Hi Danny!
So you are saying that this is a valid path specification in Windows? I did not know this. And I do not remember to ever have seen this before with Java.
Is there a reason why this "abbreviated" form is used in Java?
Has this changed recently, or did I simply never found it before?
Can this be behavior be changed to the complete path form? I like to call 'get[Absolute]Path()' in log messages and test cases, but want to see the complete path in such a case. I would like to avoid getCanonicalPath() in such cases, because this method declares an exception.
Cheers,
Michael