Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!darwin.sura.net!newsserver.jvnc.net!yale.edu!think.com!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!isgate!veda.is!adam From: adam@veda.is (Adam David) Newsgroups: comp.os.386bsd.development Subject: Re: File Truncation Philosophy Message-ID: <C4z32z.ExC@veda.is> Date: 4 Apr 93 18:52:11 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> <1993Apr2.140809.16589@cm.cf.ac.uk> <BLYMN.93Apr3213001@siren.awadi.com.au> Organization: Veda Systems, Iceland Lines: 40 blymn@awadi.com.au (Brett Lymn) writes: >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. This doesn't work. If you move the file before writing a new file, any hard links will still be permanently to the old file, which by now should have been updated (as seen by the links). It would seem that a sensible solution could work somewhat like this: When a file is overwritten which is already open, the inode becomes a "temporary inode" and has to be flagged as such. The temporary inode is made to somehow point to a new "permanent inode" (sort of like copy-on-write). When opening files, if a temporary inode is encountered, the chain is followed until a permanent inode is found and that inode is used instead of the one in the directory entry. Other file operations except for 'open' behave as normal and do not need to know about temporary inodes, so that 'read' 'write' 'seek' 'close' etc. refer to the same instance of the file that was opened even if it has been overwritten since then. Reference counts and inode-numbers in directory entries have to be transferred between the temporary and permanent inodes at suitable moments, for instance during fsck or when linked files are being opened. A temporary inode is removed along with its file when the link count drops to 0 just like normal. Given an inode-number it is necessary to know whether the inode is temporary or permanent. The rest should pretty much take care of itself unchanged. Of course it would be necessary to modify fsck and maybe a few other things which need to know about temporary inodes. Any programs which open themselves by filename while executing will break, but such programs probably deserve it. Have I missed anything important, or could this really work? -- Adam David (adam@veda.is)