Subj : REX is waiting for config files to be unlocked
To   : Nicholas Boel
From : mark lewis
Date : Sun Mar 31 2013 06:49 am


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)