ETXTBSY RE: "text file busy" and (was RE: FW: OT:
broken/useless ansi...)
Fairlight
fairlite at fairlite.com
Wed Oct 26 17:10:20 PDT 2005
With neither thought nor caution, Paul McNary blurted:
> long before SCO had anything to do with it. I feel copying over
> a binary that is use is a system management issue. Just because
> it got trapped in the old days doesn't mean it was correct
> procedure. Do you wish to have the system trap for rm -r *?
> Why is this different from any file being overwritten? UNIX
> has always allowed overwrite without notice. Do we want to go the
> Windows route and ask a dozen times if it is OK to delete?
One -GLARING- difference: `rm -r` does not crash anything that's actually
running. Or shouldn't. Only the dynamic linker being missing on a system
with dynamic binaries should be affected, and only for newly starting
processes. This -BUG- does crash things. There's a clearly delineated
difference between mis-configuration crashing something on a system, and
something that CAN NOT BE configured so as not to cause crashes.
This "management issue" trap-door you want to create for them is tantamount
to saying that the Ford Pinto explosions were the drivers' fault. Not
buying it. Your `rm -r` example is poor, at best.
A "management issue" is somewhat like the fool that put a pliable styrofoam
cup of hot coffee between her legs at McD's drive-thru. This bug is
more akin to a Ford Pinto bursting into flames, or an Audi's accelerator
sticking and sending someone into an accident. One knows (or should) what
`rm -r` does--it's destructive. You don't expect normal use to yield
unexpected results that are destructive. (Crashing out like that can be
destructive.) And after somewhere around a decade of OSR not having this
issue, this -is- unexpected--or people would not suddenly be complaining.
You also 'know', therefore, that `cp` should not be yielding its current
behaviour, even though it's the underlying VM that's at issue. The
underlying VM is b0rk3n, and should be fixed so it does not cause software
to produce anomalous results. They recalled the Pintos and Audis. They
should patch the VM here.
Any attempt to justify this unexpected and incorrect behaviour is pretty
much futile. One is always welcome to try. It can be entertaining to
knock down the straw men--for a while.
mark->
--
There is no "I" in TEAM.
This would be the primary reason I've chosen not to join one.
More information about the Filepro-list
mailing list