Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: File Truncation Philosophy
Message-ID: <1993Apr8.002028.2376@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <C4u8y2.HCM@ns1.nodak.edu> <CGD.93Apr1204906@eden.CS.Berkeley.EDU> <1993Apr2.072443.790@cm.cf.ac.uk>
Date: Thu, 8 Apr 93 00:20:28 GMT
Lines: 34
In article <1993Apr2.072443.790@cm.cf.ac.uk> paul@isl.cf.ac.uk (Paul) writes:
>What about users moving their own binaries around. If cp et al don't
>work properly then aren't users (including root) just as likely to bring
>the system down when they overwrite running binaries.
>
>We're not just talking about installation and init updates. You can't
>expect novice users to know that they shouldn't copy foo.new to foo
>while they're running foo.
The problem occurs because the program that dies is integral to the running
system; I haven't been able to crash it with a normal user program getting
trashed (on the other hand I could just be lucky). The init program on the
other hand is "fairly critical". 8-).
The cannonical fix is EBUSY or ETXTBSY from itrunc. A prettier fix is to
make the VM system own the file pages -- after all, the pages have to be
written for the blowup to occur, and copy on write would save us...
although "copy on write to swap" would be more appropriate. I can live
with the canonical fix, but want the prettier fix, since the file would
act like it *wasn't* a swap store... the same actions would be required
on any inode write attempt, not just truncation.
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------