🚀 go-pugleaf

On Sunday, in article <818620669snz@webcor.demon.co.uk>
     phil@webcor.demon.co.uk "Phil Martin" wrote:

PM> In article <818613360.3018@thokk.demon.co.uk>
PM>            Malcolm@demon.net "Malcolm Muir" writes:
PM> 
..
PM> > A pedant of course has to point out that SnzPrune does corrupt the
PM> > database in the process of deletion :)
PM> >
PM> > The fact that the resulting corruption (the renumbering of articles)
PM> > is not noticed by the majority of users is key here.
PM> 
PM> So that's why anything I read in a session that is followed by a Prune,
PM> is returned to unread status ?

<gobsmacked>

I don't recall hearing of this problem before.  Certainly
doesn't work that way for me.

The .nrc file, that contains the numbers of the articles
read, is updated by Prune, along with all the other files
relevant.  The user should see no difference, except the
absence of those articles that were marked for deletion.

Perhaps this is a support issue, not development, though
since I don't regularly read d.i.s.pc, I'm glad you've
raised it here.  I suggest we take this to email, and
come back here later, to reassure others it's either not
a problem, or will be fixed soon.

SnzPrune 0.1 is unable to cope with multiple .nrc files.
I wonder if this was a problem for you, and in kluging
around it you're restoring your original .nrc files?
SnzPrune 0.2, just released, does handle multiple .nrc
files, so you should no longer have to get 0.1 to do
more than it was designed to do.  (Lord grant me the wisdom
to document restrictions of a program clearly, not simply
give an error message after a prospective user has gone
to the trouble of downloading it -- phew, did I have cause
to regret that).   :-(

--
John Washington