Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!sdd.hp.com!crash!fredbox!loodvrij
From: loodvrij@freds.cojones.com (Loodvrij)
Newsgroups: comp.os.386bsd.development
Subject: Re: File Truncation Philosophy
Message-ID: <oDXe2B1w165w@freds.cojones.com>
Date: Fri, 02 Apr 93 19:08:59 AST
References: <C4tJ6C.C17@ns1.nodak.edu>
Reply-To: loodvrij@fredbox.cts.com
Organization: Radio Free Fredbox
Lines: 54
tinguely@plains.NoDak.edu (Mark Tinguely) writes:
> ******** Request for Comments ********
>
> As most of you know that with 386bsd installing a new copy of a running
> program causes the running program to crash and core. This happens due to
> couple of things. Fist, with the Mach VM used in 386bsd, executing
> instructions are paged directly from the executable in the filesystem
> (whereas old BSD VMs copy the executable to swap and page from there).
> Secondly, programs like "cp" TRUNCATES the existing file when copying in
> the new copy of the program. When the executing program does the next page
> fault the fault will fail and the program will crash/core.
>
Surely the 'correct' behaviour is for the open to fail with a 'text file busy'
error, no? If the system allows a running executable to opened under these
cirumstances, it damn well shouldn't.
> The easy fix is to move or remove the file before installing the new
> program. The filesystem does work correctly and keep a copy of the executabl
> and the VM still finds and uses this copy.
>
> It would be NICE to not have to worry about unlinking the file associated
> with running programs before making our copies. Nate and all the others
> working the patchkit are interested in this, also very important if the user
> is restoring from a backup (as I learned once).
>
> The philosophy question is should we change "cp" and "cat" to unlink (remove
> the file before opening? Or even lower in the filesystem (as would need be i
> the restore example).
>
Egad, NO! I've written scripts that rely on cp just opening the file for
writing, that might be broken by this behaviour. And if I have, you can bet
lots of other people have. It would certainly break the case where you wish
to overwrite a writable file in a non-writable directory, and also where the
destination file is a link. And I hate to think of the consequences if it
were a device. And what has cat got do with this anyway? It never even tries
to write a file.
> I can think of several reasons to not do this:
> 1) won't have the same inode.
> 2) won't cover all cases -- using open(2) and O_TRUNC will still
> cause the same problem.
>
> If you have other ideas or opinions, flame away.
>
Yeah, why not do this in install?
Bruce
_______________________________
Bruce J. Keeler (Ye Olde British Weirdo) | "We are the knights who say: |
Internet: loodvrij@fredbox.cts.com | COBOL !!!!!" |
Voice: (907) 337-8193, Place: Anchorage, AK |_______________________________|