standards/41576: ln(1): replacing old dir-symlinks

Alexander Best arundel at
Sat Aug 21 09:50:03 UTC 2010

The following reply was made to PR standards/41576; it has been noted by GNATS.

From: Alexander Best <arundel at>
To: bug-followup at
Subject: Re: standards/41576: ln(1): replacing old dir-symlinks
Date: Sat, 21 Aug 2010 09:41:35 +0000

 i believe this PR should be closed and the STANDARDS section of ln(1) should
 state that ln (as of r195768) conforms to IEEE Std 1003.1-2008.
 this is an excerpt from the "informative" section of IEEE Std 1003.1-2008'es
 ln specs:
 "The CONSEQUENCES OF ERRORS section does not require ln -f a b to remove b if a subsequent link operation would fail.
 Some historic versions of ln (including the one specified by the SVID) unlink the destination file, if it exists, by default. If the mode does not permit writing, these versions prompt for confirmation before attempting the unlink. In these versions the -f option causes ln not to attempt to prompt for confirmation.
 This allows ln to succeed in creating links when the target file already exists, even if the file itself is not writable (although the directory must be). Early proposals specified this functionality.
 This volume of POSIX.1-2008 does not allow the ln utility to unlink existing destination paths by default for the following reasons:
 The ln utility has historically been used to provide locking for shell applications, a usage that is incompatible with ln unlinking the destination path by default. There was no corresponding technical advantage to adding this functionality.
 This functionality gave ln the ability to destroy the link structure of files, which changes the historical behavior of ln.
 This functionality is easily replicated with a combination of rm and ln.
 It is not historical practice in many systems; BSD and BSD-derived systems do not support this behavior. Unfortunately, whichever behavior is selected can cause scripts written expecting the other behavior to fail.
 It is preferable that ln perform in the same manner as the link() function, which does not permit the target to exist already.
 This volume of POSIX.1-2008 retains the -f option to provide support for shell scripts depending on the SVID semantics. It seems likely that shell scripts would not be written to handle prompting by ln and would therefore have specified the -f option.
 The -f option is an undocumented feature of many historical versions of the ln utility, allowing linking to directories. These versions require modification"
 although earlier in the draft one can find the following:
 Force existing destination pathnames to be removed to allow the link."
 the explanations from the "informative" section of ln seem to make it clear
 that the -f switch'es purpose is for scripts etc. to never receive a
 diagnostic message.
 i believe the line:
 "The -f option is an undocumented feature of many historical versions of the ln utility, allowing linking to directories. These versions require modification."
 implies that ln -f should indeed follow symlinks and the current behaviour of
 ln -f is correct. GNU versions of ln behave just the same. BSD ln even comes
 with an -n option (which is an alias for -h) for GNU compatibility reasons.
 it would be nice if somebody could look into this, confirm that this PR can be
 closed (or sate why he thinks it should be kept open) and commit the change to

More information about the freebsd-standards mailing list