🚀 go-pugleaf

In article <92349.214819RFM@psuvm.psu.edu> RFM@psuvm.psu.edu writes:
>In article <1992Dec14.212902.1390@rei.com>, fox@rei.com (Fuzzy Fox) says:
>>
>>>   I don't think Stacker itself is unstable...either the 1.x or 2.0 or 3.0
>>>versions, in so much as the comation of Stacker + some operating systems +
>>>some drivers + some motherboards is unstable.  In other words, it no more
>>>unstable than any other program.
>>
>>My experience seems to indicate that Stacker is as (un)stable as the
>>person using it.
>>
>I take exception to this. I am as unstable as they come, but my STACKER
>1.0 has been plunking along in a 20-meg notebook for 18 months or so.
>I've got an unopened copy of Stacker 2.0 -- I'm afraid to mess with
>what's been working ok up 'till now.
>
>BobM, PSU-Harrisburg

I suspect that stacker (I use V2.1, but I guess it applies to all
releases) is rather "picky" about getting stuff actually written to the
disk!

I run the (Windows 3.1 flavour) SMARTDRV disk cache, and have noticed
that I seem to get a "rebuilding allocation ..." session on bootup if I
have NOT taken care on closing down previously. By "taken care" I mean
executed "smartdrv /c" to flush the buffers before switching off.

I THOUGHT that smartdrv intercepted the 3-fingered-salute and did a
flush, but it appears not to....


I think that this (user) instability may have a lot to do with some of
the stacker problems that people have. I guess that if you let the PC
sit for a while before switching off, then the "timed" flush sorts
things out too.

Pure speculation....
Neil
-- 
Neil Watson, ESDG Product Support, Concurrent Computer Corp
G0BLD        227 Bath Road, Slough, Berks, SL1 4AX, England
             Phone: (+44) 753 513360  FAX: (+44) 753 513303 
(nnw@slough.ccur.com, nnw@concurrent.co.uk or 100021,3041 @ Compuserve)