Hi
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]
--
http://blog.nigjo.de/netbeans
https://threema.id/3Y279Z3U
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
