Re: ln -fs "repoints" file symbolic links, but not directory symbolic links

[Bob Proulx]

Arvizu, Bob (CONT) wrote:
> Premise:  ln command should work the same as it does on Unix

Thank you for your report.  However the GNU 'ln' command follows the
BSD tradition and not the System V tradition concerning the use of
'ln'.  Since symbolic links originated with BSD and were added to AT&T
Unix later this makes sense.  Personally I prefer the SysV behavior
but GNU has been this way for a long time.

> Bug:
> Repointing a symbolic file link works properly; however,
> repointing a symbolic directory link fails.

See the -n option documentation.

  $ info coreutils 'ln invocation'

  `-n'
  `--no-dereference'
     Do not treat the last operand specially when it is a symbolic link
     to a directory.  Instead, treat it as if it were a normal file.

     When the destination is an actual directory (not a symlink to one),
     there is no ambiguity.  The link is created in that directory.
     But when the specified destination is a symlink to a directory,
     there are two ways to treat the user's request.  `ln' can treat
     the destination just as it would a normal directory and create the
     link in it.  On the other hand, the destination can be viewed as a
     non-directory--as the symlink itself.  In that case, `ln' must
     delete or backup that symlink before creating the new link.  The
     default is to treat a destination that is a symlink to a directory
     just like a directory.

     This option is weaker than the `--no-target-directory' (`-T')
     option, so it has no effect if both options are given.

However since that option does not exist in SysV Unix the portable
solution is to remove the target first with 'rm -f' before creating
the symlink.

> Significance:  Repointing of a directory symbolic link would be
> virtually instantaneous; with this bug, we must remove, then re-create
> directory symbolic links; meaning the link won't exist for the time
> between the rm and the (new) ln.

That is incorrect.  Even in the SysV Unix case there is a gap between
the time the 'ln' command removes the target and it creates the new
link file.  The only way to avoid the race condition is to create the
link with a differently named target and then rename(2) it into place.

> The information contained in this e-mail is confidential and/or proprietary
> ...

Please see this reference.

  http://goldmark.org/jeff/stupid-disclaimers/

If you can't avoid your company from putting those onto your email
then please sign up for one of the many free email providers on the
net and use those accounts for sending questions and reporting bugs.

Bob