Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!menudo.uh.edu!uuneo!sugar!peter From: peter@NeoSoft.com (Peter da Silva) Subject: Re: File Truncation Philosophy Organization: NeoSoft Communications Services -- (713) 684-5900 Date: Fri, 16 Apr 1993 21:44:53 GMT Message-ID: <C5LJ2u.1Ep@sugar.neosoft.com> References: <C5FJx6.o5w@ns1.nodak.edu> <C5G44z.8A5@sugar.neosoft.com> <1993Apr16.044053.10665@fcom.cc.utah.edu> Lines: 26 In article <1993Apr16.044053.10665@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: > In article <C5G44z.8A5@sugar.neosoft.com> peter@NeoSoft.com (Peter da Silva) writes: > >In article <C5FJx6.o5w@ns1.nodak.edu> tinguely@plains.NoDak.edu (Mark Tinguely) writes: > >> the dumb approach. > >> Once the file starts executing, fail writes to the file. > >Better: if the file is open for writing, fail the exec. The file is probably > >in an inconsistent state anyway, and it doesn't make sense to trust it. > Do this *as well*, _not_ *instead*! Oh, well, of course. I thought that went without saying. > Both of these are failure modes in the current implementation. Traditional > handling is to return an EBUSY in case 1 and an ETXTBSY in case 2. An > EBUSY is acceptable, but ETXTBSY is not (if Posix compliance is desired). So return EBUSY both times. Personally, I don't see why adding error returns not mentioned by POSIX violates POSIX compliance. Does POSIX explicitly state that there are no further returns possible, or that ETXTBSY is explicitly illegal? And even if it does, why would any reasonable application care? -- Peter da Silva. <peter@sugar.neosoft.com>. `-_-' Oletko halannut suttasi tänään? 'U` Tarjoilija, tämä ateria elää vielä.