Actual behavior
$ ide ln -s -r conf conf-link
Due to lack of permissions, Microsoft's mklink with junction had to be used to create a Symlink. See
https://github.com/devonfw/IDEasy/blob/main/documentation/symlink.adoc for further details. Error was: C:\Users\joerg\projects\test\conf-link: A required privilege is not held by the client
Junction created for conf-link <<===>> conf
$ cd ..
$ mv test test2
$ cd test2
$ ls -la
...
lrwxrwxrwx 1 joerg 197121 33 May 27 11:25 conf-link -> /c/Users/joerg/projects/test/conf
...
$ cd conf-link
bash: cd: conf-link: No such file or directory
So the relative option does not work as expected.
Reproduce
On a regular windows installation as a non-administrator user simply go to your project root ($IDE_HOME) and do
ide ln -s -r conf conf-link
Expected behavior
A relative link should be relative and not absolute.
IDEasy status
IDE_ROOT is set to ~/projects
IDE_HOME is set to ~/projects/project
Your version of IDEasy is 2026.05.001-05_27_03-SNAPSHOT.
You are using a SNAPSHOT version of IDEasy. For stability consider switching to a stable release via 'ide upgrade --mode=stable'
Your version of IDEasy is 2026.05.001-05_27_03-SNAPSHOT but version 2026.05.001-20260527.032443-21 is available. Please run the following command to upgrade to the latest version:
ide upgrade
Your operating system is windows(10.0)@arm64 [Windows 11@aarch64]
You are online.
Found bash executable at: C:/Program Files/Git/usr/bin/bash.***
Found git executable at: C:/Program Files/Git/**********/bin/git.***
Your settings are not up-to-date, please run 'ide update'.
Successfully completed ide (status)
Related/Dependent issues
No response
Comments/Hints
This is not a bug of #1847 but was already present before in our link logic but was never properly tested since it was never so easy to test it explicitly without the new ln commandlet.
According to my observations this is not a bug in our code (read the log output carefully) but a bug or lack of feature of windows (junctions).
Windows regularly restricts symbolic links for normal users what is the root problem of all the trouble.
We spent a lot of investigations into workarounds for this problem since otherwise all would already solved with Java's build-in Files.createSymlink function.
Therefore, if that fails and we are on windows we fallback to mklink /j what creates a Junction (a symlink for a directory would be mklink /d but that again requires the lacking permission).
By using MS-DOS CMD terminal and doing mklink /d conf-link conf manually I got the exact same result.
So Junctions do not seem to support relative target pointers.
At the moment the only idea I have left would be the following:
- The
link function of FileAccess will be changed to return a LinkType telling what link type we actually created. In case of a junction, we would return null.
- The
ln commandlet would check that result in case -r was given (relative.isTrue()). If the result is null, it would log a warning explaining the user that it was not possible to create a relative link due to Windows restrictions with the link to the wiki page explaining how to fix the problem by granting yourself rights with administrative permissions.
Further, if we again improve this link functionality, I would propose to do an additional improvement:
When the regular link creation fails due to permissions issues and we are on windows we do that fallback that is currently implemented in the following way:
- try junction instead (
mklink /j)
- if even the junction failed, create a hardlink instead.
However, now that I analysed the situation in Windows I come to the following conclusion:
- If you have according permissions you will never reach the workaround
- if you do (What applies to 99% of all windows users), then fallback 1. will always only work for directories but fail for files and fallback 2. will always only work for files but fail for directories.
Therefore, I conclude that the current implementation strategy does not make sense.
If we have a file to link and we enter the fallback we will always do 1. but it will ALWAYS fail and we have to do 2. as secondary fallback.
So instead we can simply check if the source is a directory and then create the junction as fallback but otherwise create the hardlink as fallback.
Actual behavior
So the relative option does not work as expected.
Reproduce
On a regular windows installation as a non-administrator user simply go to your project root ($IDE_HOME) and do
ide ln -s -r conf conf-linkExpected behavior
A relative link should be relative and not absolute.
IDEasy status
Related/Dependent issues
No response
Comments/Hints
This is not a bug of #1847 but was already present before in our link logic but was never properly tested since it was never so easy to test it explicitly without the new
lncommandlet.According to my observations this is not a bug in our code (read the log output carefully) but a bug or lack of feature of windows (junctions).
Windows regularly restricts symbolic links for normal users what is the root problem of all the trouble.
We spent a lot of investigations into workarounds for this problem since otherwise all would already solved with Java's build-in
Files.createSymlinkfunction.Therefore, if that fails and we are on windows we fallback to
mklink /jwhat creates a Junction (a symlink for a directory would bemklink /dbut that again requires the lacking permission).By using MS-DOS CMD terminal and doing
mklink /d conf-link confmanually I got the exact same result.So Junctions do not seem to support relative target pointers.
At the moment the only idea I have left would be the following:
linkfunction ofFileAccesswill be changed to return aLinkTypetelling what link type we actually created. In case of a junction, we would returnnull.lncommandlet would check that result in case-rwas given (relative.isTrue()). If the result isnull, it would log a warning explaining the user that it was not possible to create a relative link due to Windows restrictions with the link to the wiki page explaining how to fix the problem by granting yourself rights with administrative permissions.Further, if we again improve this link functionality, I would propose to do an additional improvement:
When the regular link creation fails due to permissions issues and we are on windows we do that fallback that is currently implemented in the following way:
mklink /j)However, now that I analysed the situation in Windows I come to the following conclusion:
Therefore, I conclude that the current implementation strategy does not make sense.
If we have a file to link and we enter the fallback we will always do 1. but it will ALWAYS fail and we have to do 2. as secondary fallback.
So instead we can simply check if the source is a directory and then create the junction as fallback but otherwise create the hardlink as fallback.