Path: utzoo!attcan!uunet!crdgw1!uakari.primate.wisc.edu!sdd.hp.com!ucsd!ames!haven!mimsy!mojo!mojo!djm From: djm@eng.umd.edu (David J. MacKenzie) Newsgroups: comp.unix.wizards Subject: Re: ln -f Message-ID: Date: 27 Jul 90 04:25:58 GMT References: <3732@auspex.auspex.com> <1056@undeed.UUCP> Sender: news@eng.umd.edu (The News System) Organization: Free Software Foundation Lines: 23 In-Reply-To: barrett@undeed.UUCP's message of 25 Jul 90 11:20:57 GMT In article <1056@undeed.UUCP> barrett@undeed.UUCP (Alan P. Barrett) 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. The difference might be important in some > applications. Wrong. There is no way to clobber file2 and replace it with a hard link in an atomic operation. link(2) requires that the target file not exist, otherwise it fails with: EEXIST The link referred to by name2 does exist. Versions of ln that allow an existing target file remove it first with unlink(2). There is a *shorter* window during which file2 doesn't exist than if rm(1) were used because there isn't the extra time of starting up a new process in between the link and unlink operations, but there *is* a window. -- David J. MacKenzie