FYI: `ln -i' behavior change

[Jim Meyering]

FYI,

I've just changed `ln -i' so that it does something useful
when you respond in the affirmative to the prompt about an
existing destination file.

Before, in spite of your saying to go ahead and replace
the existing destination, it'd always fail:

  $ touch a b
  $ /p/bin/ln -i a b
  ln: replace `b'? y
  ln: creating hard link `b' to `a': File exists

[that's because the link and symlink system calls always fail
 if the destination file exists]

Now, if you give the go-ahead, it unlinks the destination
before attempting to perform the link (or symlink with -s).

POSIX doesn't specify a -i option for ln, and the only systems
I know of that support ln's -i option (Darwin 7.9.0, FreeBSD)
already exhibit the new behavior.

Not only does this make more sense from a common sense perspective,
it also makes `ln -i' consistent with the way `mv -i' and `cp -i'
work for writable, existing destination files.

Note however, that cp -i works differently when the destination
is not writable:

  $ touch a b; chmod 0 b; cp -i a b
  cp: overwrite `b', overriding mode 0000? y
  cp: cannot create regular file `b': Permission denied

This behavior of `cp -i' is mandated by POSIX.  If you don't like that,
currently you may use the --remove-destination option, but in general,
using that option is not a good idea since it'd make cp unlink an
existing destination unconditionally, thus leaving an interval during
which the file is missing.  Hmm... but if you care about such things,
you shouldn't be using cp to copy directly to the destination in the first
place (try rsync instead), since it typically overwrites an existing file,
in place, which means the destination file may be incomplete during the
copy operation.