🚀 go-pugleaf

In article <830566222snz@wbriscoe.demon.co.uk>
           walter@wbriscoe.demon.co.uk "walter briscoe" writes:

>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.

Where is this version?  Any chance of a copy of the source?

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

That's something I want, I have a lot of "keep forever" newsgroups...

>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.

Even I don't usually accuse the electricity company of sabotage.
Perhaps if I do that next time there's a power cut I might get some
results <g>...

>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.

Actually, the logical order is by the size difference between before and
after expiry.  For which you have to do the expiry first, and then do
the sort, and then the expiry...

In practice, sorting in order of text file size is probably going to
give almost as good results...

>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.

I agree.

>As the sizes of articles are determinable from the index, copy
>operations can be done in units of a large buffer rather than lines.

Yes, that's what I'd expect.

>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.

In fact, it blows up with out of memory errors at around 6000 articles
for me (depending on the article size)...

.-------------------------------.-------------------------------------.
|    chris@keris.demon.co.uk    |  FIAWOL (Filking Is A Way Of Life)  |
`-------------------------------^-------------------------------------'
      This message is void in Germany, China, the United States,
       and other places where free speech is prohibited by law.