Re: Bug or feature? replace symlink to directory with ln -fs does not work

[Bob Proulx]

Just to tie the archive together, here is a previous discussion:

  http://lists.gnu.org/archive/html/bug-fileutils/2003-10/msg00000.html

Paul Eggert wrote:
> address@hidden (Bob Proulx) writes:
> > Only -s and -f are required.
> 
> Yes, but POSIX requires the GNU "ln" behavior that the original requester
> <http://lists.gnu.org/archive/html/bug-coreutils/2005-05/msg00167.html>
> objected to.  This behavior uses only -s and -f.

Ah, I see.  I was confusing Jim's the -n suggestion with your note.

Saying simply "POSIX requires the GNU and Solaris behavior" did not
provide enough grip for me to know we whether we were talking options
or transparency of symlinks to directories or default removal of the
target link.  I assumed options.

Meanwhile, I am not convinced POSIX says this.  We would have to dig
into exactly what is meant by "destination" in the standard and how
that differs from or is the same as "target_dir".  I am sure you
disagree but I believe the standard is ambiguous on this point of
exactly what should happen in the case of a symlink to an existing
directory and it would require a clarification to remove this
ambiguity.

But this is not important to me at this moment.  I am more concerned
with the practical implication and that is that the legacy SysV-like
unix 'ln' command behaves differently than the BSD-like 'ln' command.
Existing implementations make depending upon one or the other behavior
in the case of symlinks to a directory non-portable.  The only
portable solution is to remove the target first.

  rm -f alink
  ln -s adir alink

> Actually, HP-UX is the odd man out here.  GNU "ln" is compatible
> with Solaris (at least Solaris 10, which I just checked).  And
> POSIX requires the GNU and Solaris behavior.

Add IBM AIX to your "odd man out" list then.  I just verified that AIX
behaves the same as HP-UX when the target is a symlink to a directory.

I think what you will find is that all of the tranditional legacy
SysV-like systems behave the same with regards to symlinks to a
directory.  I don't think this is a case of an odd man but rather one
of the classic splits between BSD and SysV where there will be lots of
examples on both sides.

If POSIX required -n then one could portably use ln -sfn in scripts
and that would solve the problem too.  I would be perfectly happy with
that.

> Assuming GNU ln, the other options (which are extensions to POSIX)
> come into play only if you don't like the behavior required by POSIX
> here.  The original requester appears to be in that position.

As I read the original note it could be taken either way.  But I read
it as asking if the GNU ln was not behaving the same as traditional
unix systems.

  Peter Kratzer wrote:
    Contrary to the Unix behaviour (e.g. HP-UX) using this command on
    a GNU/Linux system does not replace the link, but creates a new
    link in the originally referenced directory.  Is this a bug, or is
    this behaviour intentional?

The answer depends on if you believe SysV to be traditional or BSD to
be traditional.  But symlinks originated in BSD so there is a strong
weight toward BSD with regards to behavior surrounding symlinks.

> >> Perhaps you can file a bug report with HP.

Changing this would break legacy scripts written to expect the
traditional SysV behavior.  (I know this because I always hear about
it from my coworkers when they port code.  So it does occur at a
non-zero frequency.)  Given the likelihood of breaking existing
scripts I can't see any reason for HP or IBM to want to make this
change since customers buying those systems are doing so to run
applications that need just that particular environment and this would
possibly break them.  Best case would be the addition of the -n option
to both the HP-UX and AIX ln commands.

Bob