Date: Sat, 21 Aug 2010 09:50:03 GMT From: Alexander Best <arundel@freebsd.org> To: freebsd-standards@FreeBSD.org Subject: Re: standards/41576: ln(1): replacing old dir-symlinks Message-ID: <201008210950.o7L9o34b009265@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR standards/41576; it has been noted by GNATS. From: Alexander Best <arundel@freebsd.org> To: bug-followup@freebsd.org Cc: 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: "-f 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 ln(1). cheers. alex -- a13x
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201008210950.o7L9o34b009265>