🚀 go-pugleaf

Tom Wheeley <tomw@tsys.demon.co.uk> wrote:
>In article <829872205snz@siberia.demon.co.uk>
>           philip@siberia.demon.co.uk "Philip McNab" writes:
>
>> On Thursday, in article <829827671snz@wash.demon.co.uk>
>>      john@wash.demon.co.uk "John Washington" wrote:
>> 
>> JW> Same comments also apply to SnzPrune.  I've been a bit fearful
>> JW> ... I have the impression that
>> JW> space reporting is erratic on some combinations of [waves hands].
>> JW> Not sure if it's BC++ 3.1 run time, which OS, or what.
>> JW> More detail, anyone?
>> 
>> I've only heard of this prob on compressed drives: their ideas of
>> free space seem pretty random.

Running in a dos box under an "O/S" with a dynamic swapfile on the 
same partition also springs to mind ...

>Surely it must be possible to make EXPIRE not mess up the indices when it
>does run out of space ?  That is the main concern, really.

I fixed this in some patches I sent to Malcolm a couple of weeks back 
by re-correcting the active file numbering on a 'disk error' - just 
thinking about it again, I can't see a reason why the changes to 
the active file need to be flushed with each article expired since the 
new article file and index don't replace the old ones unless it's 
successful anyway ...  (fixed the cursor positioning so the error 
messages appear in the right place if the screen hasn't scrolled, as 
well)

Also added a check if the first article in the article file isn't 
going to be expired then skip the expire of that group since none of 
the other articles will be expired (assumes they're stored in 
increasing time order).

The combination of these two patches should allow you to run expire 
quickly and as many times as you need to free up the disk space.

Cheers, Graham.
-- 
----[ Graham E. Kinns ]----==========----< Graham@grempc.demon.co.uk >----