la la land

[sgordon at kenan.com (Seth Gordon)]

> The "solution" on some systems has been to have the delete
> return an error if the file is open.  These all lead to very tricky
> programming problems as programs need to handle the error.

It can lead to usage problems as well as programming problems.

On Windows NT, if you try to delete or rename a file that's already
open, you get a "sharing violation" error -- and as far as I know,
there's no way to tell *which* user or process is holding the file
open.  If the file you're dealing with is a DLL that
Bill-only-knows-which-utility is running, or a file that's shared
across the network and might have been left open by someone whose
screen is locked and who's on vacation for a week ... aaargh.

I suspect this is why Windows installations or uninstallations are
typically followed by a reboot -- rebooting the computer is the only
way to force all the files on the disk to close, and the installation
program can leave behind a list of things to be deleted after the
reboot.

(Was there some intelligent technical trade-off behind the choice to
run NT like this, or is it one of those legacies of DOS that can't be
worked around, or what?  They guy they hired to run the NT project in
the beginning, if memory serves, was one of the big developers of VMS,
so I would expect a certain level of clue from him....)

--
"The big dig might come in handy ... for a few project managers
 whom I think would make great landfill."  --Elaine Ashton
== seth gordon == sgordon at kenan.com == standard disclaimer ==
== documentation group, kenan systems corp., cambridge, ma ==


-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).