[context: https://gist.github.com/bodewig/1c48a3ff2faf44ec21aae93ee922c3bd]
On 2026-02-14, Stefan Bodewig wrote:
> What I didn't expect: only the result of Java21/Ant 1.10.15 on Windows
> looks like the one on Linux as far as the "relative" property is
> concerned. For the other cases it looks as if the relative resultion
> happens between a basedir that has been resolved to the
> non-linked/junctioned version and a file that still has the
> symlink/junctioned path on Windows.
The reason is the file doesn't exist. getCanonicalPath/toRealPath only
resolve symlinks for files/directories that exist. If I add
<mkdir dir="build"/>
<touch file="${tempfile}"/>
to Jens' build file just before the relative property is resolved, then
I get the expected result of build\somefile.txt.
So this means the new FileUtils.resolveFile only works properly for
existing files/directories - for others it may fail to resolve symlinks.
In most cases this is not relevant, but in Jens' case it is as we
compare a non-existent and an existent file.
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?
> 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.
new File(".").getAbsolutePath() already points to the resolved directory
when the current working directory is a symlink on Linux. It does not on
Windows.
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.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
