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.




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

Do not use relatively directory.

"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.

  xxxxx@xxxxx   2005-04-15 17:50:50 GMT
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.
Posted Date : 2008-08-18 22:08:24.0

Of course you can use something like this as a workaround:
    File dummy = new File("relativeFileName");
    File realFile = new File(dummy.getAbsolutePath());
    FileInputStream fis = new FileInputStream(realFile);

I seem to be experiencing this system too, even though the 
bug is two years old. Did some code regress?
Seeting the user.dir through System.setProperty does not 
seem to have any effect.

I have filed a similar report (#4483097) with explanation 
of what is going on: apparently, all methods of 
java.io.File which call native filesystem methods ignore 
the user.dir setting. Instead, they rely on system-
dependent relative path resolution, which, according to 
Sun's reply, "[resolves file names] against the directory 
in which the Java virtual machine was originally invoked."

Effectively this means that you cannot rely on File objects 
with relative paths in them. In particular, you should not 
pass such objects to constructors of file streams, readers, 
or writers. If you have a File object with relative path in 
it, you should use its getAbsolutePath/getAbsoluteFile 
methods (see mzip's suggestion above.) Clumsy as it is, 
this is the only workaround I know of.

I don't want to use a workaround. Why don't you do things 
properly? Is java really platform independent?. When you 
expect that working directory should be independent from 
the OS, IT IS NOT. FIX THIS!!!

Why is this not fixed!
Geez the API for File says this:
" A pathname, whether abstract or in string form, may be
either absolute or relative. An absolute pathname is
complete in that no other information is required in order
to locate the file that it denotes. A relative pathname, in
contrast, must be interpreted in terms of information taken
from some other pathname. By default the classes in the
java.io package always resolve relative pathnames against
the current user directory. This directory is named by the
system property user.dir, and is typically the directory in
which the Java virtual machine was invoked. "

The API says it should work. This needs to get fixed.
See also 4722567

Hi,

this is another consequence of this bug: When you specify 
the java.library.path as a relative path on the command line 
(e.g. -Djava.library.path=lib), then execute some misbehaved 
native code through a dll that changes the working directory 
and then try to load another dll from the relative path, it will 
fail, because the exists() check on the dll file will fail as the 
working directory has changed. The VM should be immune to 
external changes of the working directory - especially as 
there is no way within Java to set it back to where it was 
before.

How many JDK versions will pass until this bug eventually is 
being fixed?

I suppose you have to regard user.dir as read-only: it is 
given to the JVM by the OS, not the other way around.

I have looked at the java.io.File source code and can 
see the problem, in the getAbsolutePath mehtod the 
folowing code is called.

return fs.resolve(this);

where fs is the FileSystem object of the opperating 
system and resolve converst the relative path name ot 
its full path. However, any method that calles some 
form of file system opperation, for example 
createNewFile() does not call the fs.resolve(this) first 
so the file is always created in the origional working 
directory.

I think the best way to fix this would be to ignore attempts to set this property on the command line and throw an exception if the application attempts to change the property. The same should be done for any other system properties which can't usefully be changed.

Not being able to change "user.dir" is hardly a solution! That means that no-one can use relative file names with java.io.File - and that is just plain crap.

The fix to java.io.File should be easy, yet Sun haven't done it  after 6 years. Perhaps it is time to consider moving to a platform where the user has some control over relative file name resolution (ugh! dare I mention the vile C#.NET).

I think the real solution is to have system properties such as 

user.dir    // user's "home" directory
main.dir   // place where the "main" method was called
current.dir //  current working directory (if user is working with a shell, or the same as user.dir otherwise).
java.dir     // directory where JVM resides.

That would help fix most of the problems that people have, as they could work out, in a system-independent way, where their program is and where the user stores their files. 

This bug is a specialised case of the bug I reported as
5082706

The folks at sun don't like simple io related bugs...
these bugs are shifted again and again. here are my favourites (seven years of ignorance by sun):

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4057701

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4285834

let's hava a party...  dot.net resolves these bugs...

user.dir is not ment to represent the "user.dir" environment variable, it is ment to represent the users home directory. I have changed my "home" un windows. linux, and OSX, and have found no problems, however, on windows boxes, this was not easy to do, as it is a regestry entry, not an environment variable.

I accepted 

Another side-effect of this bug is that if some native code running in-process changes the working directory (Microsoft

Hi.


DO NOT MODIFY THIS BEHAVIOR UNLESS YOU ARE ABLE TO PROVE THAT ALL SECURITY MECHANISMS WILL AVOID ANY BREACH AS A RESULT OF THE CHANGE.

Specifically:  new FilePermission("*", ...), for one.

No amount of "application so-and-so would not be able to so-and-so" has bearing here.  If NetBeans needs to know some directory, specify "nb.user.dir" on the command line and use that.  There will come a day when the user will be conversant enough to know that any scripts "delivered" with an application are critical security points.

THERE IS AN IMPORTANT DIFFERENCE BETWEEN AN OPERATING SYSTEM SCRIPT AND A JAVA APPLICATION.

Operating system scripts are designed to be hand-written by the computer's user -- the owner -- not some at-whim library function for unseen code to invoke!

The point is that user.dir is not a mutable property.  This is to be specified and rigidly enforced by the user: to the point of it being a security breach if your Java code attempts to change it in a manner visible outside the VM.

Ideally, each invocation of System.getProperty("user.dir") would ask the host platform for the current user directory.  If the host does not support the notion of a user directory -- and there are such platforms, right? -- some fallback should be returned.  And then, any API method that supposedly resolves against this property should diligently check it wherever needed.

If it is impinging to consider this, remember that the notion of a separation, or mediation between an application and the host it is running on -- in other words, a viable virtual machine -- is a /new/ concept, not an old one!  The ability for some MSDOS program to "modify" the user directory, or something similar, does not make precedence for future applications.


Regards,
Steev.

The Java SE 5 documentation for System.getProperties() now contains 2 different entries.

"user.dir" is the current working directory
"user.home" the user's HOME directory

The value of "user.home" should not be changeable, but the value of "user.dir" should be changable and used for relative path to absolute path processing.    The File class allows the creation of a new directory/folder but not changing the current working directory.  Changing the current working directory as the OS level should be supported with a new method in the File class.  The value of "user.dir" should be modified be that new method so they are kept in sync.

I think that if the current work directory has to be changeable, this should be done as a method in the java.lang.Runtime class, something like

   File cwd=new File(System.getProperty("user.home"),"myapp");
   Runtime.getRuntime.setCwd(cwd);

I think the best way to fix this is to make Java open source.  Examples like this one clearly demonstrate Sun's unwillingness to support the community.  The current implementation is at odds with the specification  (see the comment by teague submitted five years ago), but the programmer's at Sun just refuse to fix it.  This is either laziness or incompetence, both of which can be addressed by open sourcing Java.

Comments - like the one submitted On 13-AUG-2006 - are making me sick :-( Mind you, this is not going to solve any real life problems...)

I've just come across this problem - code I've been working on uses setProperty("user.dir", /xyz") and works as expected most of the time because most Files are explicitly converted to absolute before native filesystem accesses. However, some aren't, leading to occasional unexpected behaviour.

I'm simply astounded by the slow and weak response to this simple problem, and it's low priority. Whatever, the technical justification for not supporting chDir, the inconsistent behaviour in File and In/OutputStreamFile should be made consistent, or at least documented in the API. Furthermore, fixing it will cause behaviour change inexisting code - probably need a flag somewhere to specifiy whether paths are resolved against jvm working directory, or user.dir, or sometimes one and sometimes the other as is the current behaviour.

I'm now a lot more sceptical about the quality of java after realising that such subtle but easily addressable problems are bnot being dealt with.

This is NOT a bug.

There's no need for Java applications to change the working directory of their own process. And there's no need to read user.dir for any other than informational purposes.

Programmers that use user.dir to resolve paths have probably not fully understood the concepts of working directory and relative paths.