Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!samsung!sdd.hp.com!spool.mu.edu!uunet!mcsun!ukc!strath-cs!baird!jim
From: jim@cs.strath.ac.uk (Jim Reid)
Newsgroups: comp.sys.sequent
Subject: Re: mv not atomic in dynix
Message-ID: <JIM.91Feb19162349@baird.cs.strath.ac.uk>
Date: 19 Feb 91 16:23:49 GMT
References: <1991Feb16.000101.4149@ux1.cso.uiuc.edu>
Sender: jim@cs.strath.ac.uk
Organization: Computer Science Dept., Strathclyde Univ., Glasgow, Scotland.
Lines: 18
In-reply-to: phil@ux1.cso.uiuc.edu's message of 16 Feb 91 00:01:01 GMT

In article <1991Feb16.000101.4149@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) writes:

   When two (or more) "mv" commands try to rename the same file OR DIRECTORY
   to two DIFFERENT names at the same time, the result can be two separate
   hard links to the same inode.  In the case of directories, "ln" (or the
   underlying system call) will refuse to allow this to happen except if the
   uid is root.

This is not unreasonable on a multi-processor with a re-entrant
kernel. On a uniprocessor, the rename() system call is "atomic"
because no other process can be executing kernel code (and renaming
the same files) at the same time. In DYNIX, it is possible for several
processes to be executing rename() at the same time on different
processors. Although hardware locks are used to synchronise access to
the inodes as their link counts are changed, this will not prevent the
behaviour you describe from happening.

		Jim