Hi all, I've run into the following little bug.

For reference, I'm using Eternal September as you can see.

In my ~/.jewsrc I currently have:

comp.lang.c: 1-254200

1. When I run SLRN, it reports that comp.lang.c has 1 new article.

2. When I select the newsgroup, it immediately reports "No unread
articles" (without showing that any have been killed).

3. The unread count does not go to 0; it stays at 1.

4. When I quit slrn, the count stays at 1-254200

The old 1.0.3 that comes from Ubuntu will flip the articles to 0,
and change to 1-254201.

I dit a "git bisect", which points to this commit:

commit 68319838d0073fc63206e17463441221be4735fa
Author: John E. Davis <jed@jedsoft.org>
Date: Fri Mar 17 23:57:51 2023 -0400

pre1.0.4-8: Added support for "OVER" defined by rfc3977

While bisecting, I reproduced the problem by manually resetting
the read range to 1-254200 to get it to show 1 unread. The
above is the first commit at which the problem appears: 1 stays 1,
doesn't update .jnewsrc.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

* Kaz Kylheku wrote:
> Hi all, I've run into the following little bug.
>
> For reference, I'm using Eternal September as you can see.
>
> In my ~/.jewsrc I currently have:
>
> comp.lang.c: 1-254200
>
> 1. When I run SLRN, it reports that comp.lang.c has 1 new article.
>
> 2. When I select the newsgroup, it immediately reports "No unread
> articles" (without showing that any have been killed).
>
> 3. The unread count does not go to 0; it stays at 1.
>
> 4. When I quit slrn, the count stays at 1-254200

This is not a bug in slrn or any other newsreader that shows the same
behaviour. This phenomenon occurs when srticles are removed from the
server by a cancel message or perl-mocem (because they are spam). The
removed article is still present, hence it shows in the article list,
but not in the spool, so the article can not be downloaded and displayed.
The articles will disappear from the overview after the next run of
expireover (run from news.daily every night).

As comp.lang.c receives a massive flood drug/med spam, this behaviour can
best be observed in this group.

--
Пу́тін — хуйло́
http://www.eternal-september.org

On 2023-09-12, Ray Banana <rayban@raybanana.net> wrote:
> * Kaz Kylheku wrote:
>> Hi all, I've run into the following little bug.
>>
>> For reference, I'm using Eternal September as you can see.
>>
>> In my ~/.jewsrc I currently have:
>>
>> comp.lang.c: 1-254200
>>
>> 1. When I run SLRN, it reports that comp.lang.c has 1 new article.
>>
>> 2. When I select the newsgroup, it immediately reports "No unread
>> articles" (without showing that any have been killed).
>>
>> 3. The unread count does not go to 0; it stays at 1.
>>
>> 4. When I quit slrn, the count stays at 1-254200
>
> This is not a bug in slrn or any other newsreader that shows the same
> behaviour. This phenomenon occurs when srticles are removed from the
> server by a cancel message or perl-mocem (because they are spam).

Okay Ray, so which is correct: slrn 1.0.3 or current?

> removed article is still present, hence it shows in the article list,

The issue is that old slrn marks the article read, bumping up the
number past it. New slrn does not advance.

(If you use the c (catch up) command on the newsgroup, then it does.)

> As comp.lang.c receives a massive flood drug/med spam, this behaviour can
> best be observed in this group.

Just not with slrn before the commit I found with git bisect.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2023-09-12, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> Just not with slrn before the commit I found with git bisect.

It's happening again.

comp.lang.c: 1-254212

There are 2 articles being reported, thus they must be 254213 and
254214.

New slrn leaves it like that; it will not increment to 1-254214 and
write the file.

Old slrn will catch the newsgroup up; no unread articles found,
and it will increment to 1-254214.

I can do that manually too by editing the file; then the newsgroup
is no longer listed as having unread articles.

The catch-up command works too.

This is a bad behavior; there is no use in leaving recalled,
inaccessible articles unread.

The program says "no unread articles found", which directly contradicts
the unread count staying at 2! No unread means zero.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> New slrn leaves it like that; it will not increment to 1-254214 and
> write the file.

> Old slrn will catch the newsgroup up; no unread articles found,
> and it will increment to 1-254214.

> I can do that manually too by editing the file; then the newsgroup
> is no longer listed as having unread articles.

> The catch-up command works too.

> This is a bad behavior; there is no use in leaving recalled,
> inaccessible articles unread.

The basic problem is that from the perspective of slrn it's an
inconsistency in the overview database (and maybe the active file; I'm not
sure precisely what the database looks like since it's been a while since
I've looked at this). There are records for two more articles, but those
articles don't exist when looked up in the spool.

The thing is, slrn doesn't know which way that inconsistency will
eventually resolve. We all know that it's probably because the articles
were deleted and thus this will be resolved by deleting the overview
records as well, and this isn't done because due to the structure of the
overview database in the most common configurations deletions are
expensive and are therefore batched. But from slrn's perspective, it's
possible that the articles are going to show up later and make the
overview correct (and there are indeed some configurations where that can
possibly happen). So it's making the conservative decision to keep
retrying those articles to see if they start working, until the overview
records are removed.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

* Kaz Kylheku wrote:

>> This is not a bug in slrn or any other newsreader that shows the same
>> behaviour. This phenomenon occurs when srticles are removed from the
>> server by a cancel message or perl-mocem (because they are spam).
>
> Okay Ray, so which is correct: slrn 1.0.3 or current?

Sorry, I didn't quite get your point.
slrn 1.0.3 does indeed mark the missing article
as read and decrements the unread articles count
accordingly. slrn pre 1.0.4 still lists it as unread,
which is glitch in the prerelease.

--
Too many ingredients in the soup, no room for a spoon
http://www.eternal-september.org

On 2023-09-12, Russ Allbery <eagle@eyrie.org> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
>> New slrn leaves it like that; it will not increment to 1-254214 and
>> write the file.
>
>> Old slrn will catch the newsgroup up; no unread articles found,
>> and it will increment to 1-254214.
>
>> I can do that manually too by editing the file; then the newsgroup
>> is no longer listed as having unread articles.
>
>> The catch-up command works too.
>
>> This is a bad behavior; there is no use in leaving recalled,
>> inaccessible articles unread.
>
> The basic problem is that from the perspective of slrn it's an
> inconsistency in the overview database (and maybe the active file; I'm not
> sure precisely what the database looks like since it's been a while since
> I've looked at this). There are records for two more articles, but those
> articles don't exist when looked up in the spool.
>
> The thing is, slrn doesn't know which way that inconsistency will
> eventually resolve. We all know that it's probably because the articles
> were deleted and thus this will be resolved by deleting the overview
> records as well, and this isn't done because due to the structure of the
> overview database in the most common configurations deletions are
> expensive and are therefore batched. But from slrn's perspective, it's
> possible that the articles are going to show up later and make the
> overview correct (and there are indeed some configurations where that can
> possibly happen). So it's making the conservative decision to keep
> retrying those articles to see if they start working, until the overview
> records are removed.

Okay.

Interstingly, the only thing changed in the slrn commit where the
behavior change occurs is using the RFC 3977 "OVER" command instead of
"XOVER" when it probes available. That's it.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOng.c: 1-254212
TE: If you use Google Groups, I don't see you, unless you're whitelisted.

Hi Russ,

> The basic problem is that from the perspective of slrn it's an
> inconsistency in the overview database (and maybe the active file; I'm not
> sure precisely what the database looks like since it's been a while since
> I've looked at this).

The high water mark never decreases in the active file as this
information is used by innd to assign the next unused article number.

Though overview data may be handled differently, I think the same rule
is also followed, and the expiry process does not decrease high water
marks in overview data, but only updates low water marks, article counts
and removes old articles. It is what I have in mind from recent
investigation in the 4 overview methods when looking at how they handle
empty newsgroups.
Just to be sure, I have just cancelled an article in a local testing
group, and will report tomorrow.

> The thing is, slrn doesn't know which way that inconsistency will
> eventually resolve. We all know that it's probably because the articles
> were deleted and thus this will be resolved by deleting the overview
> records as well, and this isn't done because due to the structure of the
> overview database in the most common configurations deletions are
> expensive and are therefore batched. But from slrn's perspective, it's
> possible that the articles are going to show up later and make the
> overview correct (and there are indeed some configurations where that can
> possibly happen). So it's making the conservative decision to keep
> retrying those articles to see if they start working, until the overview
> records are removed.

In order to improve the experience of news clients, wouldn't a
groupexacthigh parameter in readers.conf be useful in INN?
The idea would be that nnrpd would give a high water mark corresponding
to an existing article when responding to GROUP, LISTGROUP, LIST ACTIVE
and LIST COUNTS.

In Kaz's example where ~/.jewsrc has "comp.lang.c: 1-254212" but the
news server reports that the highest available article number is 254214,
using "groupexacthigh: 5" in readers.conf would result in the news
server reporting that the highest available article number is 254212.
It would probe the existence of articles from 254214 to (254214-5), and
report the highest existing one, or (254214-5), to the client.

In the latest INN 2.7.1 release, a groupexactcount parameter was added
to report the real article *count* instead of an estimate. When the
estimated count of articles is strictly smaller than groupexactcount,
nnrpd recounts the number of still existing articles, and report the
exact value. If groupexactcount is set to 0, nnrpd always recounts. If
set to 1, it never recounts.
Though exact article counts are not required by the NNTP protocol, they
may be useful to distinguish empty newsgroups by reporting an exact
count of 0 instead of an estimate of 1 (when it happens, the news client
may show that 1 article is present in the newsgroup, then it tries to
retrieve the article, and finally does not show anything to the user).
The default value for this parameter is 5.

I suggest a similar parameter for the high water mark, as it also sounds
useful (independently of whether there is a regression in slrn 1.0.4,
other news clients may also report that 2 new articles are available in
comp.lang.c but on entering the group and downloading its real overview
data, the number of new articles to read becomes 0).

I add the news.software.readers newsgroup in this discussion. Maybe
some people have there information about news clients reporting
available articles, and then nothing when entering the group?

--
Julien ÉLIE

« Life is short… so eat dessert first! »

Julien_ÉLIE wrote:

> Hi Russ,

>> The basic problem is that from the perspective of slrn it's an
>> inconsistency in the overview database (and maybe the active file; I'm not
>> sure precisely what the database looks like since it's been a while since
>> I've looked at this).

> The high water mark never decreases in the active file as this
> information is used by innd to assign the next unused article number.

>> The thing is, slrn doesn't know which way that inconsistency will
>> eventually resolve. We all know that it's probably because the articles
>> were deleted and thus this will be resolved by deleting the overview
>> records as well, and this isn't done because due to the structure of the
>> overview database in the most common configurations deletions are
>> expensive and are therefore batched. But from slrn's perspective, it's
>> possible that the articles are going to show up later and make the
>> overview correct (and there are indeed some configurations where that can
>> possibly happen). So it's making the conservative decision to keep
>> retrying those articles to see if they start working, until the overview
>> records are removed.

> In order to improve the experience of news clients, wouldn't a
> groupexacthigh parameter in readers.conf be useful in INN?
> The idea would be that nnrpd would give a high water mark corresponding
> to an existing article when responding to GROUP, LISTGROUP, LIST ACTIVE
> and LIST COUNTS.

This is how my simple nnrpd server handles this, and clients seem to respond
fine to it. Missing articles (deleted, cancelled, NoCeM) are not listed
and not counted. When the highest article is deleted, it is noted in a file
and not reused.

Here's a sample:

200 Rocksolid Light NNTP Server ready (no posting)
group rocksolid.test.test
211 180 2 214 rocksolid.test.test
quit
205 closing connection - goodbye!

Then, I delete the highest article (214)

200 Rocksolid Light NNTP Server ready (no posting)
group rocksolid.test.test
211 179 2 213 rocksolid.test.test
quit
205 closing connection - goodbye!

Then I post a new article

200 Rocksolid Light NNTP Server ready (no posting)
group rocksolid.test.test
211 180 2 215 rocksolid.test.test
quit
Connection closed by foreign host.

The same counting applies to any nnrpd commands requesting count
infomation. So far I have so far not seen any issues with clients.

--
Retro Guy

Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> writes:

> The high water mark never decreases in the active file as this
> information is used by innd to assign the next unused article number.

The initial number of unread articles is probably based entirely on the
high water mark, but to me the question is why slrn doesn't mark those
articles as read the first time you enter the group and they don't exist.
I am assuming that this is because it sees phantom OVER entries for them,
but then the articles are missing when it goes to retrieve them. This
could indicate, say, an overchan setup where the overview was written
before the article was written, so it is arguably correct to not mark such
articles as read.

If the OVER command also doesn't return any data for those articles,
though, I think slrn really should just mark them as read and move on.
Articles that are both missing and don't have OVER entries probably have
been deleted. (Although I guess this could be wrong if somehow the high
water mark got updated before *either* the article was written or the
overview database was updated. I don't remember if that can happen.)

> Though overview data may be handled differently, I think the same rule
> is also followed, and the expiry process does not decrease high water
> marks in overview data, but only updates low water marks, article counts
> and removes old articles. It is what I have in mind from recent
> investigation in the 4 overview methods when looking at how they handle
> empty newsgroups.

I thought the overview data for the deleted article would be dropped from
the database during nightly expire, so will not appear in the OVER output,
but it's been a while since I looked at it so I could be wrong. In other
words, I think you're correct that the high water marks would not change,
since that's how INN ensures that it never reuses an article number, but
when you run OVER on the group, I believe the entries for those articles
should be missing.

> In order to improve the experience of news clients, wouldn't a
> groupexacthigh parameter in readers.conf be useful in INN? The idea
> would be that nnrpd would give a high water mark corresponding to an
> existing article when responding to GROUP, LISTGROUP, LIST ACTIVE and
> LIST COUNTS.

Yes, that would also solve the problem. It won't avoid the appearance of
three unread articles and then seeing only one unread article the next
time an article arrives that isn't deleted, but I think that's unavoidable
in the protocol.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Hi Russ,

>> Though overview data may be handled differently, I think the same rule
>> is also followed, and the expiry process does not decrease high water
>> marks in overview data, but only updates low water marks, article counts
>> and removes old articles. It is what I have in mind from recent
>> investigation in the 4 overview methods when looking at how they handle
>> empty newsgroups.
>
> I thought the overview data for the deleted article would be dropped from
> the database during nightly expire, so will not appear in the OVER output,
> but it's been a while since I looked at it so I could be wrong. In other
> words, I think you're correct that the high water marks would not change,
> since that's how INN ensures that it never reuses an article number, but
> when you run OVER on the group, I believe the entries for those articles
> should be missing.

The entries for cancelled articles no longer are in the overview data
returned by an OVER request. When processing a cancel, the rows are
deleted in ovdb/ovsqlite database and the index entry is deleted in
tradindexed. OVER no longer shows them.
The expiration process will then properly remove the overview data in
tradindexed.

The use case when the overview data is still present but no longer the
article, is when using CNFS and the article has been overwritten. OVER
will report the article until the next expire run.

>> In order to improve the experience of news clients, wouldn't a
>> groupexacthigh parameter in readers.conf be useful in INN? The idea
>> would be that nnrpd would give a high water mark corresponding to an
>> existing article when responding to GROUP, LISTGROUP, LIST ACTIVE and
>> LIST COUNTS.
>
> Yes, that would also solve the problem. It won't avoid the appearance of
> three unread articles and then seeing only one unread article the next
> time an article arrives that isn't deleted, but I think that's unavoidable
> in the protocol.

Ah yes, indeed, there may be gaps in the available article numbers. The
problem solved here would be to show unread articles whereas there are
no new articles to read, but not the exact count of unread articles,
which is impossible to know from a mere GROUP command.
The client may send a "LISTGROUP latest high-new advertised high"
command and counts itself, but it will slow down a bit the reading
experience.

--
Julien ÉLIE

« Sum, ergo bibo ; bibo, ergo sum. »

Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> writes:

> The entries for cancelled articles no longer are in the overview data
> returned by an OVER request. When processing a cancel, the rows are
> deleted in ovdb/ovsqlite database and the index entry is deleted in
> tradindexed. OVER no longer shows them.

Oh! Okay, so my diagnosis of the problem was wrong because I forgot that
we did hide the overview information immediately.

So you're right, this probably is entirely about the high water mark.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Responding to my previous article:
> The high water mark never decreases in the active file as this
> information is used by innd to assign the next unused article number.
>
> Though overview data may be handled differently, I think the same rule
> is also followed, and the expiration process does not decrease high water
> marks in overview data, but only updates low water marks, article counts
> and removes old articles.
> Just to be sure, I have just cancelled an article in a local testing
> group, and will report tomorrow.

I confirm the high water mark does not decrease in the overview data
after an expiration run. Same thing as for the active file.
The expiration process properly cleans up the related (hidden) expired
overview data, as discussed yesterday.

--
Julien ÉLIE

« Donec eris felix, multos numerabis amicos. » (Ovide)

* Julien ÉLIE wrote:
> Responding to my previous article:
[...]
> I confirm the high water mark does not decrease in the overview data
> after an expiration run.

That's good to know, as anything else would break the xrefslave feature.

;-)

--
Пу́тін — хуйло́
http://www.eternal-september.org

On 2023-09-13, Ray Banana <rayban@raybanana.net> wrote:
> * Julien ÉLIE wrote:
>> Responding to my previous article:
> [...]
>> I confirm the high water mark does not decrease in the overview data
>> after an expiration run.
>
> That's good to know, as anything else would break the xrefslave feature.
>
> ;-)

In any case, about the slrn behavior, it goes away if I make this change
to the code to disable the use of OVER instead of XOVER.

diff --git a/src/nntplib.c b/src/nntplib.c
index 595c6c8..596a453 100644
--- a/src/nntplib.c
+++ b/src/nntplib.c
@@ -842,12 +842,14 @@ int nntp_has_cmd (NNTP_Type *s, char *cmd)
if (!strcmp (cmd, "XOVER"))
{
if (s->can_xover != -1) return s->can_xover;
+#if 0
if (1 == _nntp_probe_server (s, "OVER")) /* rfc3977 */
{
s->can_xover = 1;
s->xover_cmd_name = "OVER";
return 1;
}
+#endif
return PROBE_XCMD(s, s->can_xover, cmd);
}

It's strange. While there are only junk articles you get the behavior
that it doesn't catch up. Currently there are 5. As soon as a 6th
article shows up that is good, then when I read it, slrn will catch
up and there will be 0 unread.

There must be a protocol level difference between what slrn is getting
from OVER vs XOVER.

I'm suspecting that in the situations in which this manifests itself,
OVER is reporting fewer articles than the watermark, which differs from XOVER.

And then slrn is refusing to catch up beyond what was reported by OVER.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Hi Kaz,

> It's strange. While there are only junk articles you get the behavior
> that it doesn't catch up. Currently there are 5. As soon as a 6th
> article shows up that is good, then when I read it, slrn will catch
> up and there will be 0 unread.
>
> There must be a protocol level difference between what slrn is getting
> from OVER vs XOVER.
>
> I'm suspecting that in the situations in which this manifests itself,
> OVER is reporting fewer articles than the watermark, which differs from XOVER.
>
> And then slrn is refusing to catch up beyond what was reported by OVER.

The same overview data is returned by OVER and XOVER.
The only protocol level difference is the response code when an empty
range is given as the argument to the command. OVER returns 423 (no
articles) whereas XOVER returns 224 (OK) without any subsequent information.

Example of newsgroup with high number = 27 but article number 27 is not
available, and you have "comp.lang.c: 1-26" in your .slrnrc file.

GROUP comp.lang.c
211 21 1 27 comp.lang.c

STAT 27
423 No such article number 27

OVER 27-
423 No articles in 27-

XOVER 27-
224 No articles in 27-
..

Maybe this slight difference triggers the behaviour slrn has when using
OVER because it does not handle the 423 response code as equivalent to
XOVER returning no articles at all?

--
Julien ÉLIE

« L'éternité, c'est long, surtout vers la fin. » (Woody Allen)

On 2023-09-14, Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> wrote:
> Maybe this slight difference triggers the behaviour slrn has when using
> OVER because it does not handle the 423 response code as equivalent to
> XOVER returning no articles at all?

Thanks Julien,

I see in slrn where it treats anything other than 224 as an error
and returns -1, in a certain function.

But 423 isn't an error; it's just a positive indication that there are
no articles.

I am testing a change now.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2023-09-12, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> Hi all, I've run into the following little bug.
>

I have a fix for this now.

commit 5b43b2e927f51e30fe1ec14242cdd573ee143621
Author: Kaz Kylheku <kaz@kylheku.com>
Date: Wed Oct 4 20:46:47 2023 -0700

bug: OVER issue: not advancing past articles.

We need to handle the 423 code (ERR_NOARTIG) when OVER is used
instead of XOVER. Just pretending that it is 224 (OK_XOVER)
doesn't work because the code then tries to get headers,
and the connection will abruptly close unlike in the XOVER
case.

The manifestation of the problem is like this. Sometimes
a certain newsgroup shows a positive number of articles
unread. When an attempt is made to select the newsgroup,
slrn shows "No articles unread" --- but the count does not
go to zero. It does not advance the article count.

* src/art.c (get_headers): Do not bail if slrn_open_xover
returns ERR_NOARTIG (423). Furthermore, in this case, do not
try slrn_read_xover, because the socket will close, which
causes a problem. We just skip over the loop, to the state
updates at the end of the function.

diff --git a/src/art.c b/src/art.c
index 66bc1d5..9cbcfa7 100644
--- a/src/art.c
+++ b/src/art.c
@@ -5714,10 +5714,9 @@ static int get_headers (NNTP_Artnum_Type min, NNTP_Artnum_Type max, NNTP_Artnum_
/* slrn_set_suspension (1); */
err = slrn_open_xover (min, max);
- if (err != OK_XOVER)
+ if (err != OK_XOVER && err != ERR_NOARTIG)
{
- if ((err == ERR_NOCRNT) || /* no articles in the range */
- (err == ERR_NOARTIG)) /* this one is not RFC 2980 compliant */
+ if ((err == ERR_NOCRNT))
return 0;
return -1;
@@ -5726,7 +5725,7 @@ static int get_headers (NNTP_Artnum_Type min, NNTP_Artnum_Type max, NNTP_Artnum_
num_processed = 0;
expected_num = min;
num = Total_Num_Headers + Number_Killed;
- while (slrn_read_xover(&xov) > 0)
+ while (err != ERR_NOARTIG && slrn_read_xover(&xov) > 0)
{
NNTP_Artnum_Type this_num;

Hi Kaz,

> bug: OVER issue: not advancing past articles.
>
> We need to handle the 423 code (ERR_NOARTIG) when OVER is used
> instead of XOVER. Just pretending that it is 224 (OK_XOVER)
> doesn't work because the code then tries to get headers,
> and the connection will abruptly close unlike in the XOVER
> case.

Thanks for the fix for slrn!

(If slrn ever implements HDR, there's also a similar difference between
the results of HDR and XHDR on empty responses.)

--
Julien ÉLIE

« Le carré est un triangle qui a réussi, ou une circonférence qui a mal
tourné. » (Pierre Dac)