Path: utzoo!attcan!uunet!wuarchive!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!dkuug!freja.diku.dk!skinfaxe.diku.dk!thorinn
From: thorinn@skinfaxe.diku.dk (Lars Henrik Mathiesen)
Newsgroups: comp.unix.wizards
Subject: Re: ln -f
Message-ID: <1990Aug9.200735.5493@diku.dk>
Date: 9 Aug 90 20:07:35 GMT
References: <3732@auspex.auspex.com> <1056@undeed.UUCP> <3770@auspex.auspex.com>
Sender: news@diku.dk (The Netnews System)
Organization: Department Of Computer Science, University Of Copenhagen
Lines: 32

guy@auspex.auspex.com (Guy Harris) writes:
>>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....

Why don't the versions of ln that you know of on 4.3 BSD and SunOS 4
use the rename system call?

    idavolde 2 >man rename
    ...
    DESCRIPTION
	 Rename causes the link named from to be renamed as to.  If
	 to exists, then it is first removed.  ...

	 Rename guarantees that an instance of to will always exist,
	 even if the system should crash in the middle of the opera-
	 tion.

I've heard that it was precisely because of the various race
conditions in connection with ln that made Berkeley put the function
into the kernel where inodes could be locked and updates done in
proper order.

--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark      [uunet!]mcsun!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers.      thorinn@diku.dk