Eric Blake <[EMAIL PROTECTED]> wrote: > Contrast the following: > > $ mkdir a b c > $ echo 1 > a/f > $ echo 2 > b/f > $ cp -v a/f b/f c --remove-destination > `a/f' -> `c/f' > cp: will not overwrite just-created `c/f' with `b/f' > > with the similar: > > $ rm c/f > $ ln -vf a/f b/f c > `c/f' => `a/f' > `c/f' => `b/f' > $ cat c/f > 2 > > Oops - we overwrote the just-created c/f with a link to b/f. Similarly > with ln -s, where we lose the just-created link to a/f.
Good catch. Fixing this is important to avoid loss that would otherwise happen like this: ln -f a/f b/f c && rm -rf a b If ln succeeds, the user should be assured that removing the just-linked files is ok, since there should be hard links in c/. If ln exits successfully but leaves no link to one of the source files, then a user running the above will lose whatever is in "a/f". My working sources now detect this, but only when creating hard links. I.e., if you repeat the original experiment with symlinks, a just-created symlink will be clobbered, but you won't lose anything in the file system. Everything needed to recreate what might be considered to be lost (the symlink values) is on the command line. FWIW, you can avoid this by using ln's --backup=numbered option. At least on the command line, that avoids the risk. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
