On 2026/02/14 16:59:08 Stefan Bodewig wrote:
> getCanonicalPath/toRealPath only
> resolve symlinks for files/directories that exist.
Actually Path#toRealPath always throws if the file doesn't exist (and is
documented to do so).
The real difference between Windows and Unix is in getCanonicalPath which
doesn't resolve symlinks in ancestors on Windows if the file itself doesn't
exist. It
does (in Java 24+) if the file exists. On Linux (where I tested it), it will
resolve symlinks
in ancestors in either case.
> We could (a) live with it and document it, (b) try to be smart make
> getResolvedPath walk up a files parents until it finds one that exists,
> resolve that and then append the paths we've stripped back again. Any
> other ideas?
I intend to open a bug report on this with Java. And by now I believe we must
implement
the "walk up the tree" fallback in Ant in order to avoid breaking builds.
Builds already
break for people upgrading Java running the last released version of Ant.
> > Another difference is that on Linux Ant has already resolved the symlink
> > from the start. ${ant.file} and ${basedir} point to the real paths while
> > they are still their symlinked/junctioned version on Windows.
>
> This is Java's File constructor.
I'll also open a bug report about that.
> Should be try to emulate Linux behavior on Windows? I.e. set basedir to
> the resolved symlink junction when starting? I'm not sure this would
> break more things.
I'd leave it at what we currently have.
Something I also realized during testing is that because of this running a
build via
<antcall> setting the basedir sees a different basedir than running a fresh Ant
build
inside the directory of the antcall'ed build. We don't resolve the "basedir" so
it ends up
with unresolved symlinks. I'd document this.
Also I'm thinking about adding a new attribute to <property location> that
would resolve
symlinks/junctions before setting the property.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
