United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4117557 File.getAbsolutePath() is incorrect if "user.dir" is set on the command line
JDK-4117557 : File.getAbsolutePath() is incorrect if "user.dir" is set on the command line

Details
Type:
Bug
Submit Date:
1998-03-06
Status:
Closed
Updated Date:
2008-08-18
Project Name:
JDK
Resolved Date:
2008-08-18
Component:
core-libs
OS:
windows_nt,linux,generic,windows_xp,windows_2000
Sub-Component:
java.io
CPU:
x86,generic
Priority:
P5
Resolution:
Won't Fix
Affected Versions:
1.1.5,1.2.0,1.2.2,1.3.0,1.4.0,1.4.1,5.0,6u10
Fixed Versions:

Related Reports
Duplicate:
Duplicate:
Duplicate:
Duplicate:

Sub Tasks

Description
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)

Hi;

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)
======================================================================

                                    

Comments
SUGGESTED FIX

Check the field used in File class, maybe help
                                     
2004-10-01
WORK AROUND

Do not use relatively directory.
                                     
2004-10-01
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
                                     
2005-04-15
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.
                                     
2008-08-18



Hardware and Software, Engineered to Work Together