Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!snorkelwacker!bloom-beacon!eru!luth!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: <1990Aug17.111157.19464@diku.dk>
Date: 17 Aug 90 11:11:57 GMT
References: <1056@undeed.UUCP> <3770@auspex.auspex.com> <1990Aug9.200735.5493@diku.dk> <3873@auspex.auspex.com>
Sender: news@diku.dk (The Netnews System)
Organization: Department Of Computer Science, University Of Copenhagen
Lines: 25

guy@auspex.auspex.com (Guy Harris) writes:
>[I write:]
>>Why don't the versions of ln that you know of on 4.3 BSD and SunOS 4
>>use the rename system call?
I tried to cancel this as soon as I realized my error, but it didn't
work, evidently.

>["rename" is]
>     an atomic operation that *renames* the source to the target, and if
>it succeeds does *not* leave the source behind.

I [usually] know that. But now that I think about it: Why doesn't ln:
	1) Create a new, randomly named, link in the target directory.
	2) Use "rename" to atomically replace the target with that link?
There will be no time when the target name doesn't exist. If the
machine crashes (or ln is killed), a funny link may be left behind,
but I think that is a smaller problem than the timing race.

I don't know if it would be wise to make this the default behaviour of
ln, but it might be useful to provide it as an option. (Of course, the
method would only be used if the target already existed.)

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