Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!husc6!seismo!ll-xn!cit-vax!mangler
From: mangler@cit-vax.Caltech.Edu (System Mangler)
Newsgroups: net.unix-wizards
Subject: Re: Which commands (in /bin & /usr/bin) must have set user ID (for root)
Message-ID: <1082@cit-vax.Caltech.Edu>
Date: Sun, 26-Oct-86 20:00:40 EST
Article-I.D.: cit-vax.1082
Posted: Sun Oct 26 20:00:40 1986
Date-Received: Mon, 27-Oct-86 05:18:11 EST
References: <115@tijc02.UUCP> <735@hropus.UUCP> <1040@ho95e.UUCP> <8545@sun.uucp>
Organization: California Institute of Technology
Lines: 21
Summary: dual-port disks

In article <8545@sun.uucp>, guy@sun.uucp (Guy Harris) writes:
> In a system using NFS, it is impossible to prevent a file from being opened
> for writing by a process on one machine if another machine is using that
> file as a shared text (because it's impossible for the machine on which the
> file resides to find out who's holding on to it), so the writes are allowed
> to go through; however, if the process using that file tries to fetch a
> page from a file that has been modified since the process in question first
> attached to it, it gets zapped by a SIGKILL (a message is printed on the
> user's terminal, if there's a terminal associated with this process).

This problem is even worse with dual-ported disks.  The read-only side
is completely clueless about the writes, and the process (usually some
daemon like sendmail) gets a mixture of old and new pages.  If you're
lucky, the process dies.  We only update the read/write side late on
Saturday nights, but we still get bit.

/etc/update's liking for holding certain directories open all the time
causes similar problems when those directories are updated.  I've never
understood the purpose of that.

Don Speck   speck@vlsi.caltech.edu  {seismo,rutgers}!cit-vax!speck