*BSD News Article 13936


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!news-feed-1.peachnet.edu!umn.edu!noc.msc.net!uc.msc.edu!raistlin!timbuk.cray.com!hemlock.cray.com!overby
From: overby@cray.com (Glen Overby)
Subject: Re: File Truncation Philosophy
Message-ID: <1993Apr2.132122.5267@hemlock.cray.com>
Lines: 24
Nntp-Posting-Host: fig15
Organization: Lego Land
References: <C4tJ6C.C17@ns1.nodak.edu>
Date: 2 Apr 93 13:21:22 CST

In article <C4tJ6C.C17@ns1.nodak.edu> tinguely@plains.NoDak.edu (Mark Tinguely) writes:
> As most of you know that with 386bsd installing a new copy of a running
> program causes the running program to crash and core. This happens due to

Some Unix systems have an errno for this, ETXTBSY.  This still exists
in 386BSD's <sys/errno.h>, but is surrounded by #ifndef _POSIX_SOURCE.
If you want to have only POSIX-sanctioned errno returns, then the
second candidate I'd suggest is EBUSY, which is defined by 1003.1, but
isn't listed as an errno returned by open().

I think returning an error when opening an executing binary r/w is
preferable to having cp unlink before opening, as that unlink will
break hard-links.

What to do after getting the error is up to the implementer of the
backup program.  IMHO, that would be the right time to consider an
unlink.  In the fine Unix tradition, most probably just throw the file
away and go on; if it was VAX/VMS, you'd create another version of the
file, and on IBM big iron you'd ABEND :-) In this respect, 386BSD's
current actions are most like the latter blue box.

Does POSIX.2 address this issue?  I expect not as POSIX.1 does not.

Glen Overby