Xref: utzoo comp.bugs.sys5:662 comp.unix.wizards:12088 comp.unix.questions:10039
Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!mejac!gryphon!desint!geoff
From: geoff@desint.UUCP (Geoff Kuenning)
Newsgroups: comp.bugs.sys5,comp.unix.wizards,comp.unix.questions
Subject: Re: ln(1) and System V
Message-ID: <1808@desint.UUCP>
Date: 2 Nov 88 08:48:57 GMT
References: <1988Oct31.141701.11055@utfyzx.uucp>
Reply-To: geoff@desint.UUCP (Geoff Kuenning)
Distribution: na
Organization: Interrupt Technology Corp., Manhattan Beach, CA
Lines: 37

In article <1988Oct31.141701.11055@utfyzx.uucp> harrison@utfyzx.UUCP (David Harrison) writes:

> Recently Geoff Collyer (utstat!geoff) has pointed out that under System 
> V the command:
> 	ln old new
> will destroy "new" if it already exists.  Historically and under other 
> UNIX versions the same command will complain and refuse to make the link.  
> Geoff calls the System V behaviour "an unintuitive shock". It certainly 
> breaks any program that relies on `ln' refusing to link to "new" as a way
> of doing locks (including parts of Cnews).
...
> code like:
> 	if [ !exists new ]	# new command `exists'
> 	then
> 		ln old new
> 	fi
> leaves a terrible window of vulnerability between the test and the
> link.

After seeing this, I checked on my system, since several of my important
scripts use 'ln' to implement locks.  However, I found that all of these
scripts use the following sequence to make the lock:

	trap "" 1 2 15
	touch lock
	ln lock lock1  ||  exit 1
	trap "rm -f lock lock1; exit 1" 1 2 15

This *will* work, because ln will fail complaining the "lock" and "lock1"
are identical.

On the other hand, if your scripts use the following sequence, they will
fail to lock on System V:

	touch lock.$$
	ln lock.$$ lock  ||  exit 1
-- 
	Geoff Kuenning   geoff@ITcorp.com   uunet!desint!geoff