Re: [9fans] Ephase question.

[presotto@plan9.bell-labs.com]

> - Unix' solution of making the remove fail with "file busy"; it was
> always inconvenient and confusing.  They use that one for in use
> executables.

I'm clearly misremembering.  I was thinking of overwrite.  Don't know
why, had to remove a file last week on an SGI system to do just that.

> The really interesting question is how much pain did that cause when
> porting/rewriting software from Unix.  creat()/unlink()/work with fd
> you'd got from creat()  is definitely a common idiom.  OTOH, most of
> its uses are for situations when you either want remove-on-close
> or are messing with shared directories...
>
> How bad it had it actually been?

Russ addressed the ape library.

As someone, Rob?, has already mentioned, the close on remove
flag (ORCLOSE) flag on open/create does the same thing as unlinking
immediately after opening.

My biggest headache has been replacing running binaries.  Since we
can't remove them or overwrite them without disasterous consequences,
we end up with a 'safeinstall' option in all our mkfiles.  The safeinstall
moves the file to an unlikely name (e.g. x -> _x) and copies in the
new file.  Of course, since we have dozens of machines all running off
the same file system,  something is probably running off the _x that
was there.  So we sometimes have to move _x to __x, etc.  It's a
royal pain.  We often forget and just install with the result that
someone an hour after the fact in some other part of the building
sends you a snap or pointer to a broken process.  Since I don't have
to implement the fs, I'ld have preferred the Unix semantics in this
case.  It's caused me a lot of inconvenience over the last 10+ years.

> "Accident" in this case need not imply "unintentional".
> When Canaday et al. invented the inode-based system,
> it is conceivable that they thought the semantics were
> just what they wanted.

Since the same 'et al' implemented both the first Unix fs
and the first Plan 9 fs, I'll ask him and see what he says.