pushing the investigation, it seems to only be an error on my side. I used to do this on file, but when doing it on a directory, it creates a link inside the linked directory instead of updating the current link. Sorry about that, the main issue can be closed for me.
however, the behavior is a bit confusing, without the f option, ln fail saying that the destination file exists, and with it, it doesn't overwrite ii but instead create a new link inside it. Either the destination is the link that should be updated, and it is ok to fail without -f but it should be updated with -f either the destination is a new link inside the directory and it can be created without -f Le mar. 2 févr. 2021 à 14:27, Michael Stone <mst...@debian.org> a écrit : > On Tue, Feb 02, 2021 at 10:46:29AM +0100, cedric borgese wrote: > >Package: coreutils > >Version: 8.32-4+b1 > >Severity: normal > >X-Debbugs-Cc: cedric.borg...@gmail.com > > > >Dear Maintainer, > >trying to update a symbolic link from a nfs share silently fails. > >if the symbolic link /some/nfs/share/tmp already exists, the command > >ln -sv /tmp /some/nfs/share/tmp > >fails as expected with an error message, but the command > >ln -svf /tmp /some/nfs/share/tmp > >fails and print an output as if the link was succesfully updated > > I can't duplicate on nfs. I'd guess there's something on the NFS server > preventing the command from succeeding but I can't be more specific > without more information. What should actually be happening is that ln > makes an attempt to create the symlink, that fails, then it makes the > link with a random name and renames it into place. If you run your > command with strace you can see the exact system calls. >
