Win95 service (was: Re: [RC5] DES-II-3 [LONG] [Repost])
lyndon at kcbbs.gen.nz
Thu Sep 3 22:10:33 EDT 1998
That's exactly what happens to me (except that the machines in question
are rebooted at least once a day). I've checked fairly carefully, and
the number of blocks in buff-in decreases without a corresponding increase
in buff-out if the machine is rebooted frequently.
Reading through the FAQ, it seems that this is, as you suggest, a Windows
problem. The answer is to use a checkpoint file (which can't be shared
between computers). The length of time between checkpoints determines
how much is lost (and the checkpoint means that the lost stuff is just
redone, instead of being gone forever).
On Wed, Sep 02, 1998 at 10:56:27AM -0600, Steve Bird wrote:
> Here's a perfect example..
> I'm using the Win32 CLI version on an NT machine running on a P2/266 with
> 64MB of ram. This machine is left on 24/7/365.
> I get blocks to this machine via sneakernet.
> I requested 300 blocks, however, right now it says that the amount of blocks
> in the buff-out.rc5 file is 256 and the number of files in the buff-in.rc5
> file is 40. I know that the client works on 2 blocks simultaneously,, but
> what happened to the other 2 blocks??
>>Lyndon, the blocks are probably there (we hope) but
>> obviously when the
>>OS shuts down it isn't sending the WQuit to the application,
>> but instead
>>simply pulls it's CS memory allocation from the stack. The
>>could be in the programme or the OS itself.
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5