[PATCH] strange behavior after cancelling an article

Hello,

attached patch deals with this TODO entry:

!o  after cancelling an article, when using '-' form the next article  
this
!   article is also marked as unavailable.
!   <nntp://news.tin.org/[email protected]>
!   [20070202 Urs Janssen <[email protected]>]

When the second (the next) article is displayed, this_resp points to  
the second article.

After using '-' from the second article page.c:load_article() does a  
art_close(&pgart) and rfc2046.c:art_open() memsets pgart to zero.  
load_article() exits with GRP_ARTUNAVAIL because art_open returnes  
ART_UNAVAILABLE.

When trying to read the second article again this_resp equals to  
new_respnum in load_article() and art_open() isn't called. pgart  
contains nothing useful and (pgart.cooked == NULL) becomes TRUE ->  
load_article() issues a wait_message and returnes GRP_ARTUNAVAIL.

This happens also when art_open() returnes ART_ABORT.

Steps to reproduce this:
1. display an article
2. go to the next article and *immediately* 'q'uit the loading process
3. answer the abort-question with 'y'
4. try to display the article from #1 again -> article unavailable

Step #2 needs quick fingers to trigger the failure ;-)

Another way to trigger these failures is to use the "Fake art  
unavailable" code in page.c:load_article() (works only after removing  
"cLINES," from the function call). Read an article -> call the next  
article and declare it unavailable -> try to read the first article  
again -> article unavailable too.

Summary:
In such situations this_resp points to an article which is not 'open'  
anymore and load_article() doesn't (re)open it because this_resp  
equals to new_respnum.

possible fix:
Set a flag in load_article() after art_open() returns ART_UNAVAILABLE  
or ART_ABORT. This flag forces load_article() to 'reopen' the article  
even if this_resp equals to new_respnum.

Dennis