Bug#617402: expanded description

[Achiel van der Mandele]

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.