🚀 go-pugleaf

In article <830462963snz@tsys.demon.co.uk>
           tomw@tsys.demon.co.uk "Tom Wheeley" writes:

> In article <830215383snz@wash.demon.co.uk>
>            john@wash.demon.co.uk "John Washington" writes:
> 
> > wb> to be expired.  Making them unread would do that for me with the revised
> > wb> specification.
> > 
> > I have thoughts of a 'keep' function in snews, implemented much
> > the same way as 'delete' and SnzPrune.
> > 
> > Also SnzPrune ought to be able to note Supersedes lines
> > and/or Expires.
> 
> Methinks that the logical step here would be to merge Expire and Snzprune
> into one big messy meaty conglomerate utility, which would take note of any
> Expires and Supercedes: headers (with perhaps min, max and default expiry
> times) etc.
> 
> This program would also skip gracefully any newsgroups it cannot expire,
> without messing up indices.  It should also process the newsgroups in size
> order (smallest first), to try to prevent disk full errors.  This wonder
> utility should also cause porcine creatures to become airborne... ;)

I now have an expire which:
1) Does not corrupt active if the disk does not have enough room.
2) Skips newsgroups where the expiry time is negative
3) Skips newsgroups where the first article is younger than the expiry
time
4) Optionally, keeps unread articles where there is only one user.

It is a lot faster as a result of 2&3.

It can still fail if a file renaming or delete operation fails.  The
only ways I can think of making that happen involve sabotage. e.g.
Giving a file a read attribute or the power switch.

It did not seem worthwhile to expire groups in order of increasing size
as a disk full error ought to be an unusual event.  Those users with
interest in this direction should be aware that there is no ordering
constraint in ACTIVE and sorting it by size of article file should not
be difficult.  Even so, the logical order is by size AFTER EXPIRY.

I would like to make it faster by making more use of index file.
Current logic says an article is a sequence of bytes whose start address
is in the index file and which ends which starts or consists of a
case-insensitive "@@@@END".  The logic of the code is inconsistent!

Although the current code does not depend on this, I reckon that
adjacent index entries should refer to adjacent articles with neither
gaps between nor overlaps of articles.
As the sizes of articles are determinable from the index, copy
operations can be done in units of a large buffer rather than lines.

I was thinking of direct access to a read file buffer passed in by
setvbuf but the standard says: "The contents of the array at any time
are indeterminate."

BTW, I read an earlier article where Philib McNab suggested that expire
should take note of prune files.  I would not have thought there was a
problem with the current expire program because it does not renumber
articles but merely beheads the list in each newsgroup.

There is a potential problem with reindex but that does not interest me
at the moment.

Does anybody have any information on limits in Snews?  I don't think it
will cope with more than 32767 articles in a group because Borland's
malloc seems to have that limit and the article read list is
implemented as a byte array.  Long before one got to that point, I
imagine the process of dynamic threading would have become unreasonably
slow.
--
walter briscoe