NB>> The only way you'll be able to fix that problem is to set Windows 
 NB>> to download the updates, but not apply them or reboot your machine 
 NB>> until you say so. That way you can safely download/install 
 NB>> updates, shut down Irex safely, and reboot. 

 ML> that may not always work the way you want it to... m$ can still 
 ML> override and force the update in along with the reboot... this is 
 ML> exactly what happened to bob juge's large and very popular 
 ML> system... it corrupted the VM that his fidonet stuff was running 
 ML> in, the backups were bad, and the drives the original image(s) 
 ML> were made from were no longer available... it was too much to 
 ML> loose and too much to try to recover so he ended up leaving 
 ML> fidonet because of it... it was a huge blow to the network and 
 ML> there was a lot of folks having to adjust their systems to connect 
 ML> elsewhere for their traffic...

 NB> Eh.. I've always been able to set Windows to download updates, but
 NB> never install them until I tell it to. This problem may lie in the
 NB> fact that noone ever takes a LOOK at the updates before they
 NB> install them. You DO have the option to NOT install an update if
 NB> you don't want to.

true but this is not what happened to bob's system... an update was forced by
m$ even though his settings were to not apply them automatically... the update
then required a reboot which it also performed... apparently that reboot
process didn't shutdown the VM and corrupted it beyond recovery...

 NB> Letting everything M$ puts through go by is a problem in itself. 

i've only had problems with update a few times in all the years since w9x came
out... they were worse in the beginning but have gotten better... most of
those problems were hardware driver related... outside of that, my systems
have installed all security and important updates...

 NB> That's why I switched to Linux over a decade ago, and only keep a 
 NB> small Windows partition for any gaming addiction I may encounter. 
 NB> :)

linux updates have their own problems, too ;)

 NB> As for the huge system you speak of, they basically lost interest,
 NB> more or less. If they were still interested, they would have come
 NB> back up from scratch, because that's what Sysops do. Simple rescans
 NB> would have gotten them their message bases back in order.

you can't rescan what isn't available from your upstream... there weren't many
top level hubs retaining messages for rescans...

 NB> I/You/We/All of us may back up our stuff daily, but if the interest
 NB> isn't there anymore, that's it.

unless a backup is tested by restoring it, one will never know if it is good
or not until it is too late... even then it may work for one or two test
restores and fail on the one that's absolutely necessary... i can't count the
numbers of times that i've run backups with verification that all passed but
were total garbage when needed for restoring... especially bad were the
corporate ones for my clients at the time... the worst was after investing in
DAT tape backup as an upgrade from the "normal" tape backup stuff...

i won't even mention the problem of where to backup to...

in any case, bob worked on his system for a week or two trying to recover it
and it was just too much... one of the problems with starting over again was
also that the OS being run in the VM was not windows and his setup was not
workable in windows... kinda like mine... there's no way i can do on windows
or linux what i do in OS/2... especially not with how i've used 4DOS/4OS2
scripting capabilities and definitely not with all the DOS software in
operation... heck, it won't even work in a pure DOS environment any more...

)\/(ark

--- 
 * Origin:  (1:3634/12.42)