On Wed, 12 Jun 2002 kpneal@pobox.com wrote:

# On Wed, Jun 12, 2002 at 04:17:35PM -0400, Greg A. Woods wrote:
#
# > Maybe someday applications will all be converted to use atexit() to
# > register their cleanup routines and this silly garbage collection
# > technique will no longer be necessary at which time the unlinking of an
# > open file can be disallowed.  Maybe that should happen immediately and
# > the issue should be forced.
#
# Who wants to try to explain to users why sometimes they can rm a file
# and sometimes they can't?

Hint:  Microsoft.
Clue:  We don't want to go there.

I've never had unlink()ing problems, although I was rather fascinated
when I compiled an a.out that was running, and got the message:

a.out:  Text file busy

I'd thought that maybe unlink() should fail on a running program, but
why?  If unlink() were to fail, then by UNIX definition, rename() would
have to fail (since it consists of a link() followed by an unlink(),
even though it's now an atomic operation).

[I *would* like it very much if a shell could lock a script so that
it couldn't get written while running -- or are there still people
around who routinely write self-modifying code?  I missed that age
by a couple of years.]

# Who wants to make upgrades of a running system impossible because
# programs currently running can't be removed? I suppose you could get
# around this by renaming things first, but that seems gross and a giant
# leap backwards.

See above regarding rename...

# Warping the way the filesystem works in order to work around broken
# applications seems like the exact wrong thing to do.
#
# What's next? Eliminating use of mfs for /tmp because a system crash
# could blow away important data that a running app *might* have *possibly*
# wanted to write to a more permanent location?
#
# C'mon.

Hear, hear!

				--*greywolf;
--
NetBSD: the power to swerve (penguins, worse than cane toads).