In the systemd build scripts we have a line like this: # ln -s --relative -f /usr/lib/systemd/user-generators/ /usr/lib/systemd/system-generators/systemd-dbus1-generator When the destination doesn't exist this works correctly: # ls -al /usr/lib/systemd/user-generators/ total 4 drwxr-xr-x. 1 root root 46 3. Mär 23:36 . drwxr-xr-x. 1 root root 1836 3. Mär 23:35 .. lrwxrwxrwx. 1 root root 44 3. Mär 23:36 systemd-dbus1-generator -> ../system-generators/systemd-dbus1-generator Let's run this again now, with the sysmlink now existing: # ln -s --relative -f /usr/lib/systemd/user-generators/ /usr/lib/systemd/system-generators/systemd-dbus1-generator # ls -al /usr/lib/systemd/user-generators/ total 4 drwxr-xr-x. 1 root root 46 3. Mär 23:37 . drwxr-xr-x. 1 root root 1836 3. Mär 23:35 .. lrwxrwxrwx. 1 root root 23 3. Mär 23:37 systemd-dbus1-generator -> systemd-dbus1-generator Which is already wrong. But now starting it a third time: # ln -s --relative -f /usr/lib/systemd/system-generators/systemd-dbus1-generator /usr/lib/systemd/user-generators/systemd-dbus1-generator ln: failed to access ‘/usr/lib/systemd/user-generators/systemd-dbus1-generator’: Too many levels of symbolic links Usually, people use "-f" to make the call idempotent. But this doesn't work when combined with --relative apparently. Also, adding -n or -T doesn't fix this either. It won't fail then anymore, but it does generate a broken link every second time. Rewriting this to use "-t" doesn't make it any better...
simplified testcase: $ mkdir /tmp/test $ cd /tmp/test $ tree . |-- a `-- b 2 directories, 0 files $ ln -srf a b/c $ tree . |-- a `-- b `-- c -> ../a 3 directories, 0 files $ ln -srf a b/c $ tree . |-- a | `-- a -> . `-- b `-- c -> ../a 4 directories, 0 files
I'm rushing now, but the test cases above confuse me a bit. Anyway for idempotentency of symlinks I always use -nfs (easy to remember :)). So we did fix a related issue last year: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=e52293aa That's in v8.22 (rawhide) Without that fix, and with Harald's test case: $ ln-8.21 -nfs -r a b/c $ tree . |-- a `-- b `-- c -> ../a 3 directories, 0 files $ ln-8.21 -nfs -r a b/c $ tree . |-- a `-- b `-- c -> a 2 directories, 1 file With that fix, and rerunning Harald's test case: $ ln-8.22 -nfs -r a b/c $ tree . |-- a `-- b `-- c -> ../a 3 directories, 0 files $ ln-8.22 -nfs -r a b/c $ tree . |-- a `-- b `-- c -> ../a 3 directories, 0 files
looks good!
coreutils-8.21-21.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/coreutils-8.21-21.fc20
Package coreutils-8.21-21.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing coreutils-8.21-21.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-3488/coreutils-8.21-21.fc20 then log in and leave karma (feedback).
coreutils-8.21-21.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.