Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!convex!convex!darwin.sura.net!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!usenet.coe.montana.edu!nate From: nate@cs.montana.edu (Nate Williams) Subject: Re: File Truncation Philosophy Message-ID: <1993Apr2.024424.13864@coe.montana.edu> Sender: usenet@coe.montana.edu (USENET News System) Organization: CS References: <C4tJ6C.C17@ns1.nodak.edu> <CGD.93Apr1173018@eden.cs.berkeley.edu> Date: Fri, 2 Apr 1993 02:44:24 GMT Lines: 48 In article <CGD.93Apr1173018@eden.cs.berkeley.edu> cgd@eden.CS.Berkeley.EDU (Chris G. Demetriou) writes: > >In article <C4tJ6C.C17@ns1.nodak.edu> tinguely@plains.NoDak.edu (Mark Tinguely) writes: >>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 in >>the restore example). > >no. if you're using a program to backup/restore the contents >of your hard disk, use one that's smart enough to do it right. Huh??? Chris, what are you talking about? I re-read Mark's initial article, and nowhere in the article was backup/restore mentioned. [ discussion on which backup/restore methods are valid deleted ] > >> 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. > >you forgot one: no reason to add the complexity to all of the programs >which would need it. If the changes were made at a low enough level, could the complexity of changing all the programs be minimized? Mark? The main reason I see that something needs to change is for doing simple: make install in /usr/src. If you happen to write a new copy of /sbin/init, it is possible to take your machine down. This is a BAD THING, and either we need to kludge up install, or we need to fix the behavior of copying over running executables. It is possible (a very quick perusal of restore doesn't show it) that restore will show the same behavior as install. You can minimize this by running in single user, but I'd rather not play roulette and hope that my executable was completely in memory when I copies a new file on top of it. Nate -- osynw@terra.oscs.montana.edu | Still trying to find a good reason for nate@cs.montana.edu | these 'computer' things. Personally, work #: (406) 994-4836 | I don't think they'll catch on - home #: (406) 586-0579 | Don Hammerstrom