bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul Eggert
Subject: Re: Bug or feature? replace symlink to directory with ln -fs does not work
Date: Tue, 24 May 2005 16:49:03 -0700
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.4 (gnu/linux)

address@hidden (Bob Proulx) writes:

> 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".

Here's my reasoning.
<http://www.opengroup.org/onlinepubs/009695399/utilities/ln.html> says
"ln source target" should attempt to create a link at
target/sourcebase if if the target "names an existing directory".
<http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11>
says that pathname resolution is complete (i.e., the symbolic link is
not followed) if "The function is required to act on the symbolic link
itself, or certain arguments direct that the function act on the
symbolic link itself."  But if BAR is a symbolic link to an existing
directory, then "ln FOO BAR" is not required by the standard to act on
the symbolic link BAR itself, nor does "ln" have arguments directing
that it act on BAR itself.  Therefore "ln FOO BAR" must attempt to
create a link at BAR/FOO rather than failing because BAR exists.

The logic is the same for both "ln FOO BAR" and "ln -s FOO BAR", but I
can't help but wonder whether HP-UX and AIX treat it differently
without the -s.

> 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.

If existing practice actually disagrees in the way that you mention,
then most likely they'll resolve it by agreeing that the standard
is incorrect or ambiguous.

> The only portable solution is to remove the target first.
>
>   rm -f alink
>   ln -s adir alink

Yes, I think that's right.

There is a problem with all the approaches suggested so far, including
the HP-UX-specific method suggested by the original requester: there
is a window during which no symlink exists.

To fix that problem, do this:

  mkdir tmpdir
  ln -s dir.1 tmpdir/dirlink
  mv tmpdir/dirlink .
  rmdir tmpdir

This is portable code, and the symbolic link will always exist.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]