Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!sun-barr!cs.utexas.edu!uunet!noc.near.net!saturn.caps.maine.edu!dartvax!smoke.marlboro.vt.us!jhood From: jhood@smoke.marlboro.vt.us (John Hood) Subject: Re: File Truncation Philosophy Organization: Domestic Vorpal Bunny Breeder's Association Date: Fri, 2 Apr 1993 22:08:04 GMT Message-ID: <1993Apr2.220804.8345@smoke.marlboro.vt.us> References: <C4tJ6C.C17@ns1.nodak.edu> Lines: 31 In article <C4tJ6C.C17@ns1.nodak.edu> 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. "Use the source, Luke." I actually tried some experiments and took a look at the source code in question. 386bsd actually does the right thing for local file systems and non-root users-- it returns ETXTBSY. Root access appears to override all write-access checks; for NFS, I haven't a clue what happens, although there is some code in there that seems to be checking for busy text. So, this is either a bug or a feature. :) If it's a bug, it's easily fixed by adding/moving the check for busy text before the root check. (All this is in vfs_vnops.c, as I recall.) If it's a feature, it's time to start another debate on the purpose of 386bsd. I can think of at least one reason not to change sh open code to unlink a file before truncating it, and I'm not a unix wizard. If I can easily think of something like that, there are probably many more good reasons not to do it. --jh -- John Hood Cthulhu-- just imagine it! jhood@smoke.marlboro.vt.us Duke U, 1980: "Okay, so a few systems have the net started. What next?"