Many thanks Jens, this is exactly why I asked people to test the release
candidate.
Can you tell us which version of Java you are using?
I suspect you are using Java < 24 and things would break with Java 24+
(i.e. the current LTS of 25) for you even when using Ant 1.10.15.
Prior to Java 24 File#getCanonicalPath does not follow junctions or
symlinks on Windows while Path#toRealPath does. One change in 1.10.16 is
to use Path#toRealPath here. But if I'm correct, then the change to
getCanonicalPath in Java 24+ would have the same effect on your build.
For your specific case we probably need something like followSymlinks on
<property> that you would need to set to false in order to resolve the
file the same way as before.
Stefan
On 2026-02-09, Jens Hofschröer wrote:
> I think this _will_ break some builds. At least mine.
> I am working inside a folder from a junctioned path. In my buildscript
> I need to find a relative path to a file. This works find in 1.10.15.
> With the release candicate 1 this no longer works an my build breaks.
> I created a simple sample script to demonstrate the difference:
> ```xml
> <?xml version="1.0" encoding="UTF-8"?>
> <project name="reldemo_for_1.10.16" default="demo" basedir=".">
> <!-- create C:\Temp\reldemo and copy this file to that folder. -->
> <!-- call: mklink /J C:\Temp\reldemo_junction C:\Temp\reldemo -->
> <!-- C:\Temp\reldemo_junction> ant -->
> <target name="demo">
> <property name="tempfile" value="build/somefile.txt"/>
> <echo>target:${tempfile}</echo>
> <property name="tmp.resolved" location="${tempfile}"/>
> <echo>resolved:${tmp.resolved}</echo>
> <property name="tmp.relative" location="${tmp.resolved}"
> relative="true" basedir="${basedir}" />
> <echo>relative:${tmp.relative}</echo>
> </target>
> <!-- Result from 1.10.15:
> demo:
> [echo] target:build/somefile.txt
> [echo] resolved:d:\Temp\reldemo_junction\build\somefile.txt
> [echo] relative:build\somefile.txt
> -->
> <!-- Result from 1.10.16:
> demo:
> [echo] target:build/somefile.txt
> [echo] resolved:d:\Temp\reldemo_junction\build\somefile.txt
> [echo] relative:..\reldemo_junction\build\somefile.txt
> -->
> </project>
> ```
> The relative path needs to be resolved from the basedir. It should not
> depend on beeing inside a Junction or not.
> Greetings
> Jens
> Am 06.02.2026 um 21:31 schrieb Stefan Bodewig:
>> Hi all
>> in the "Planning a Release" thread I said
>>> Personally I have at least one Bugzilla issue I want to look into and a
>>> small improvement waiting where we can get rid of some pre-Java7ism.
>> The small improvement I had in mind was using Path.toRealPath instead of
>> getCanonical file as it was supposed to be better in some way. While
>> testing the change on Windows I realized it has in fact become inferior
>> with Java 24.
>> Until Java 24, toRealPath would resolve symlinks and junctions (a
>> special kind of NTFS only symbolic link only for directories and not
>> allowed to cross volume boundaries) while getCanonicalPath did not -
>> with 24 getCanonicalPath has caught up. Unlike getCanonicalPath
>> toRealPath throws an exception when the file or the link target doesn't
>> exist, this is why I call it inferior.
>> So instead of replacing all getCanonicalPath invocations with toRealPath
>> I plan to replace them with a wrapper than only uses toRealPath if
>> running on Windows and on Java prior to 21 and if the file actually
>> exists.
>> This change also made it easier to deal with junctions points, something
>> Maarten asked for about three and a half years ago
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=66293
>> I intend to make all of Ant treat junctions like symlinks before cutting
>> the release.
>> All of this is introduces subtle changes on Windows while nothing really
>> changes for any other platform. I don't really expect people to be
>> affected much as I don't expect file system links to be common at
>> all. In either case some extended testing by Windows users would be good
>> and I plan to ask people on the users mailing list once the RC is ready
>> to be voted on.
>> What I still plan to do:
>> * look through all tasks with special handling of symlinks and make sure
>> they also know about junctions.
>> * introduce a condition "can I create symlinks" as <symlink> should also
>> work on Windows if the stars are properly aligned (basically if Ant
>> runs as admin or developer mode is enabled). This would allow some
>> "unix only" tests to also run on (some) Windows boxes
>> * make sure the manual states what really happens WRT symlinks in
>> several places.
>> I have already introduced a new task <mklink> that only works on Windows
>> (as it uses a cmd.exe built-in) which can be used to create hardlinks,
>> symbolic links and junctions on NTFS.
>> Stefan
>> PS I learned so many new things about NTFS during this, which alone has
>> been worth the effort :-)
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
