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

When I manipulate System property "user.dir", File's getAbsoluteFile() may no
longer refer to the same file as original. Here is an example:
----------
import java.io.File;
import java.io.IOException;

public class FileAbsPathBug {
  public static void main( String[] args) throws IOException {
   // Create test file in c:/temp
    File test= new File( "c:/temp/test.txt");
    if( !test.exists()) {
      test.createNewFile();
    }
    // Set c:/temp as my base directory for resolving relative paths
    System.setProperty( "user.dir", "c:/temp/");
    // Make a relative path for the c:/temp/test.txt file we've just creared
    File f= new File( "test.txt");
    System.err.println(
      f.getAbsolutePath() +
      (f.exists() ? " exists" : " does not exist" )
    );
    System.err.println(
      f.getAbsolutePath() +
      (f.getAbsoluteFile().exists() ? " exists" : " does not exist" )
    );
  }
}
----------
Running this results in the following printout:
c:\temp\test.txt does not exist
c:\temp\test.txt exists

I suspect that this problem happens because File internally resolves existence
using FileSystem's getBooleanAttributes(this) & FileSystem.BA_EXISTS.
FileSystem.getBooleanAttribute is a native method, which is likely to not know
about "user.dir".

One fix to this would be always passing an absolute path to native methods of
FileSystem.
(Review ID: 128603) 
======================================================================

An ugly work-around is using getAbsoluteFile() on all File objects that came
from "unknown" sources, and may therefore contain a relative path (e.g. user-
supplied strings, as opposed to JFileChooser.)
======================================================================

Not a bug.  If you need to resolve a filename against the value of
the "user.dir" system property then you must use getAbsolutePath (or
getAbsoluteFile, or getCanonicalPath, or getCanonicalFile).  Simpler
operations such as exists() always resolve against the directory in
which the Java virtual machine was originally invoked (and no, there
is no way to change that).

--   xxxxx@xxxxx   2001/7/23

I believe that it is incorrect to close this report as “not 
a bug,” because the behavior of the class clearly 
contradicts the documented behavior. This automatically 
makes it a bug.
The documentation supplied with java.io.File does not 
mention anywhere that different methods of the class may 
interpret the same File object differently (in fact, 
documentation always says “the file,” implying that 
java.io.File object refers to exactly one file.) There is 
another unfortunate consequence to this inconsistent 
behavior – all classes that take instances of java.io.File 
as an argument must specify whether they resolve relative 
paths starting at the user.dir, or the JVM’s start-up 
directory. Finally, check out the bug number 4117557. That 
old bug (filed in 1998) comes from exactly the same root 
cause – some operations of java.io.File ignoring the 
user.dir setting.
At the very least, you have to change the documentation to 
clearly state which operations ignore user.dir setting 
while resolving relative paths.
As far as “no, there is no way to change that” in your 
evaluation goes – give me a break, the fix is trivial. This 
is not my guess – I looked at the source code before filing 
the bug report. If in the constructor of java.io.File you 
store the absolute path resolved with user.dir, and then 
pass this absolute path to all native methods, the problem 
will go away.
Thank you,

Sergey Kalinichenko.

I just got burned by this bug, and I wish that you would reopen it so that i could vote for it.

I agree with Sergey Kalinichenko's comments 100%.

At the very least, Sun, you need to update your javadocs for the File class and warn people about when user.dir 
is actually used or not.

I agree that this is not supposed to be 'closed'. I do 
however _not_ agree that a simple documentation change will 
suffice if the fix is in fact trivial.

Anyone come across this, please leave a comment.

H.F.

excerpt from File.java :
-----------------------------------
    static private FileSystem fs = FileSystem.getFileSystem();
[...]
    public boolean exists() {
	SecurityManager security = 
System.getSecurityManager();
	if (security != null) {
	    security.checkRead(path);
	}
	return ((fs.getBooleanAttributes(this) & 
FileSystem.BA_EXISTS) != 0);
    }
[...]
    public String getAbsolutePath() {
	return fs.resolve(this);
    }
-------------------------------------------------
As you can see, for both operations the File class delegates 
to the same object the actual implementation.
Why doesn't the FileSystem object work the same in both 
case ?

This bug is still around with JDK 1.5.0 beta 2.

I think the way to get this bug fixed is to submit another bug report with a different number, and lynch the Sun developer if they close it as "not a bug" again.

So that is what I'm gonna do :)