JDK-4117557 : File.getAbsolutePath() is incorrect if "user.dir" is set on the command line
  • Type: Bug
  • Status: Closed
  • Resolution: Won't Fix
  • Component: core-libs
  • Sub-Component: java.io
  • Priority: P5
  • Affected Version:
    1.1.5,1.2.0,1.2.2,1.3.0,1.4.0,1.4.1,5.0,6u10 1.1.5,1.2.0,1.2.2,1.3.0,1.4.0,1.4.1,5.0,6u10
  • OS: generic,linux,windows_nt,windows_2000,windows_xp
  • CPU: generic,x86
  • Submit Date: 1998-03-06
  • Updated Date: 2008-08-18
  • Resolved Date: 2008-08-18
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
While the user set uer.dir in command line, then the File initialed with an relatively directory will occur a problem:

That is, If you get it's AbsolutePath, it  relate on the dirctory which user defined. but when you test if this file exist, the related directory is still where the javaVM been setup.

Name: skT88420			Date: 12/07/99

C:\gcs\serverconnect\src\org\objectweb\jonas\tools>java -version
java version "1.2"
Classic VM (build JDK-1.2-V, native threads)


We need to set the default directory for some java tools we call (that are not
our code). We have found the following:

1) user.dir returns the default directory.

2) If you set user.dir in a program - it has no effect.

3) If you set it on the command line, it only half works.

3a) This call gives you the directory you set: new File ( fileName).getAbsoluteFile ( )

3b) This call uses the original default directory - not user.dir: newFileInputStream ( fileName )

I think this is a bug - ???

- dave
(Review ID: 98747)

EVALUATION After careful consideration, we still do not believe that the current behaviour can/should be changed. We have never guaranteed that "user.dir" will be consulted at any given time and unfortunately the jdk has assumed that this property will not change. Ideally we'd introduce the concept of a "read-only" system property to guard against unsupported changes in this and other system properties.

EVALUATION "user.dir", which is initialized during jvm startup, should be used as an informative/readonly system property, try to customize it via command line -Duser.dir=xyz will end up at implementation dependend/unspecified behavior. The current FileSystem implementation heavily depends on the assumption that we dont have a "chdir" or "chdir" like functionality (like use -Duser.dir=xyz) that will change the "current user dir" to not the one jvm startup from. That said, the inconsistent behavior of FileIn/OutputStream is indeed a buggy behavior (FileIn/OutputStream's open impl goes down to naive open directly without consulting java File/FileSystem because of the assumption mentioned above). To change the current implementation to support "customizable" user.dir is a big deal, lots of classes/lines of change, only do it if we believe it's really worth doing. ###@###.### 2005-04-15 17:50:50 GMT

WORK AROUND Do not use relatively directory.

SUGGESTED FIX Check the field used in File class, maybe help