Original description might be a little short, so here's a little extra
info.
If you request a new File("").getCanonicalFile(), the UnixFileSystem
caches the lookup for the directory *in* which the file you're
requesting is located. For the example above, that would be
"/usr/lib/jvm/ia32-java-6-sun-1.6.0.22/jre/lib/"
Inside that directory we have a symlink, "zi", to
".../../../java-6-sun-1.6.0.22/jre/lib/zi". Because of the caching,
requesting files inside zi will then return a different getCanonicalPath
than you would expect. This is noted in java.io.UnixFileSystem.java:
==
157 // Note that this can cause symlinks that
should
158 // be resolved to a destination directory to
be
159 // resolved to the directory they're
contained in
==
As can be seen in the example above, this can cause problems with
certain core api calls (in this case, getTimeZone, which returns a "GMT"
file inside zi, and subsequently checks to see if it actually comes from
java.home. This fails because the getCanonicalPath to the symlink
incorrectly resolves.)
It seems to me that the solution would be to remove the symlink and
replace it with its own copy of zi. This fix has been tested and
verified locally.
Note that this problem is not exclusive to squeeze, lenny also suffers.
__
This is the maintainer address of Debian's Java team
<http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers>. Please
use
[email protected] for discussions and questions.
