Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!network.ucsd.edu!usc!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: File Truncation Philosophy
Message-ID: <1993Apr18.012731.23976@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <C5G44z.8A5@sugar.neosoft.com> <1993Apr16.044053.10665@fcom.cc.utah.edu> <C5LJ2u.1Ep@sugar.neosoft.com>
Date: Sun, 18 Apr 93 01:27:31 GMT
Lines: 49
In article <C5LJ2u.1Ep@sugar.neosoft.com> peter@NeoSoft.com (Peter da Silva) writes:
>Terry wrote:
>> 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?
No more than a reasonable application will care if signal sets aren't
contiguous in Posix signals so that a for loop doing sigest()'s can't
ever work.
Seriously, the return codes from "system" and "exec" need to be meaningful
in all cases; that means documented, so that failures can be trapped. What
do you do in a program that returns an unexpected failure mode if the only
code you have written deals with expected failure modes?
I can't have exec() or open return ETXTBSY when it can never happen elsewhere
(the correct soloution being "do all developement on 386BSD" 8-). If I
overload EBUSY instead, I won't know whether to tell the user to take
corrective action ("quit writing the file, dummy!") or that the normal
locking protocol must be obeyed ("The file is locked by another user").
Better to "just work" in the kernel by copying to swap and retrying than
to return any error in a case that would normally result in ETXTBSY were
the kernel not trapping and handling the swap store workaround for you.
In my opinion *only* reasonable applications will have problems! It's
only the *reasonable* applications that trap and handle errors in the first
place; one anonymous failure from an *unreasonable* application is pretty
much like another, and that's where it *wouldn't* matter. The *reasonable*
applications out there are the ones that most need well defined behaviour
from the interfaces they use.
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------