Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!foxhound.dsto.gov.au!fang.dsto.gov.au!myall.awadi.com.au!myall!blymn From: blymn@awadi.com.au (Brett Lymn) Newsgroups: comp.os.386bsd.development Subject: Re: File Truncation Philosophy Date: 3 Apr 93 21:30:01 Organization: /usr/blymn/.organization Lines: 38 Message-ID: <BLYMN.93Apr3213001@siren.awadi.com.au> 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> <1993Apr2.140809.16589@cm.cf.ac.uk> NNTP-Posting-Host: siren.awadi.com.au In-reply-to: paul@isl.cf.ac.uk's message of 2 Apr 93 14:08:07 GMT >>>>> On 2 Apr 93 14:08:07 GMT, paul@isl.cf.ac.uk (Paul) said: Paul> In article <CGD.93Apr2020413@eden.CS.Berkeley.EDU> cgd@eden.CS.Berkeley.EDU (Chris G. Demetriou) writes: > >=>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. > >if they do it, then their foo will die, and that's it. Paul> Don't you think that's broken too? Paul> It's hardly desirable to be able to kill a running process by Paul> overwriting the file. Paul> I think we need to fix more than just binary installation tools. The implications of what you are proposing is a big leap backward. The reason that the binary will crash if overwritten whilst running is that the vm system does not load all of the file into memory when the application starts, only a small portion of the app is loaded and the vm system pages in the other pages on an as needed basis, the source of these pages is, of course, the disk image. Back in the 'good old days' the entire images was loaded into swap before the app started and paged from there, this is the historical reason for the sticky bit on an executable, it told the vm system that this code was likely to be used again so it should not be flushed from swap. What you will effectively be doing is filling your swap with "dead" code just to satisfy the app requirements, this is a waste of resources. What is really required is a change in user procedure. If you move the executing file to another name and then creating the new file, after a reboot the old file can be deleted, this is safe because the file is reference by it's inode not it's name. I agree the behaviour is not really desirable but the benifits of the scheme outweigh the problems and with the proper procedures there is no problem.