Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!olivea!decwrl!pa.dec.com!e2big.mko.dec.com!peavax.mlo.dec.com!paik From: paik@mlo.dec.com (Samuel S. Paik) Newsgroups: comp.os.386bsd.development Subject: Re: File Truncation Philosophy Message-ID: <1993Apr2.172944.29475@peavax.mlo.dec.com> Date: 2 Apr 93 17:29:44 GMT References: <C4tJ6C.C17@ns1.nodak.edu> <CGD.93Apr1204906@eden.CS.Berkeley.EDU> <1993Apr2.072443.790@cm.cf.ac.uk> <CGD.93Apr2020413@eden.CS.Berkeley.EDU> Sender: usenet@peavax.mlo.dec.com (USENET News System) Organization: Digital Equipment Corporation, Alpha Personal Systems Software Group Lines: 22 In article <CGD.93Apr2020413@eden.CS.Berkeley.EDU> cgd@eden.CS.Berkeley.EDU (Chris G. Demetriou) writes: >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. > >not the system, just the copied-over process will die... It seems to me the real issue here is modification of files currently in use, i.e., locking. If we really implemented, like Apollo did, exclusive and shared locks on files, then we'd avoid the problem of zapping executing processes by overwriting their binaries. This introduces a different "problem". Programs like cp (and just about anything which uses stdio), would fail if it tried to open for writing (with truncation if exists) locked files--someone complained about this recently on the net. THIS is the file truncation philosophy problem. How's this for a "solution" (unfortunately, I think this breaks POSIX): instead of doing a open for writing with truncation if exists, do a open for writing and unlink if exists. Sam Paik