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 |_______________________________|