Eric Blake wrote: > According to Eric Blake on 9/4/2009 2:06 PM: >> According to Jim Meyering on 9/4/2009 12:12 PM: >>>> copy.c needs to use #if LINK_FOLLOWS_SYMLINKS instead of #ifdef. >>> Sounds good. >> >> How about the following two patches? ... >>From 410eddc47c10082591b2487b234a3b5a6155daaf Mon Sep 17 00:00:00 2001 > From: Eric Blake <e...@byu.net> > Date: Fri, 4 Sep 2009 13:56:16 -0600 > Subject: [PATCH 2/2] ln: add comments related to POSIX 2008 > > * src/ln.c (ENABLE_HARD_LINK_TO_SYMLINK_WARNING): Delete. > (do_link): Update comments per POSIX; add FIXME for -L, -P. > --- > src/ln.c | 35 ++++++++++++++--------------------- > 1 files changed, 14 insertions(+), 21 deletions(-) > > diff --git a/src/ln.c b/src/ln.c ... > - POSIX 1003.1-2004 requires that ln -f A B must unlink B even on > - failure (e.g., when A does not exist). This is counterintuitive, > - and we submitted a defect report > - <http://www.opengroup.org/austin/mailarchives/ag-review/msg01794.html> > - (2004-06-24). If the committee does not fix the standard we'll > - have to change the behavior of ln -f, at least if POSIXLY_CORRECT > - is set. In the meantime ln -f A B will not unlink B unless the > - attempt to link A to B failed because B already existed. > + On the surface, POSIX describes an algorithm that states that > + 'ln -f A B' will call unlink() on B before ever attempting > + link() on A. But strictly following this has the counterintuitive > + effect of losing the contents of B, if A does not exist. > + Fortunately, POSIX 2008 clarified that an application is free > + to fail early if it can prove continuing onwards cannot succeed, > + so we are justified in trying link() before blindly removing B, > + and calling link() twice for a successful 'ln -f'.
Looks fine, modulo: how about adjusting via s/and/and thus sometimes/ or s/twice/a second time,/ Otherwise, it might be seen as saying there are a total of 3 link calls.
