Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!cs.utexas.edu!chinacat!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F. Haugh II)
Newsgroups: comp.unix.wizards
Subject: Re: ln -f
Summary: POSIX has sense at least ...
         ... I think.
Message-ID: <18475@rpp386.cactus.org>
Date: 28 Jul 90 20:32:40 GMT
References: <3732@auspex.auspex.com> <1056@undeed.UUCP> <3770@auspex.auspex.com>
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 29
X-Clever-Slogan: Recycle or Die.

In article <3770@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>But that doesn't give the same result.  If you remove file2 first, then
>>there is a brief window between the 'rm' and the 'ln' during which no
>>file named file2 exists.  
>>If you use a version of 'ln' that clobbers file2 and replaces it with a
>>link to file1 in an atomic operation, there is no such window.
>
>As far as I know, there's no such atomic operation, either; I sure
>haven't seen any such operation in any UNIX system I've ever run into.
>
>Given that, every version of "ln" I know of that removes the target
>first has to first "unlink()" the target, and then do the "link()".  As
>such, the window is still there....

My complaint is because 1). the behavior is useful [ obviously, since
AT&T and BSD both have ln's with different behaviors and no one has yet
decided that either is patently stupid ] 2). the behaviors are
different so you can't know whether the ln on the system you are using
is going to fail or succeed, depending on your definition of failure
or success.  Which means you are forced to use "rm -f $2 ; ln $1 $2"
to have the desired effect [ again, or not, depending on what "the
desired effect" is ].

Standardizing on "ln" and "ln -f" behavior, as I believe POSIX is trying
to do, will resolve the problem - there will be exactly one set of
POSIX-like "ln" and "ln -f" behavior.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org