denying nnimap server causes nnimap-close-group to crash

denying nnimap server causes nnimap-close-group to crash

[Steinar Bang]

Platform: Gnus v5.8.7, XEmacs 20.4, linux

When I'm at home, none of the IMAP servers at work are available, so I 
would like to deny them.

However if I go to the server buffer, and press D on these servers,
and then go back to *Group* and press 
	g
I end up with the following stack trace:

Signaling: (wrong-type-argument stringp nil)
  set-buffer(nil)
  (save-current-buffer (set-buffer nnimap-server-buffer) (when (and ... ...) (case nnimap-expunge-on-close ... ... ...) (not imap-current-mailbox)))
)
  (with-current-buffer nnimap-server-buffer (when (and ... ...) (case nnimap-expunge-on-close ... ... ...) (not imap-current-mailbox)))
)
  nnimap-close-group("INBOX" "somemachine.somecompany.no")
  gnus-get-unread-articles(2)
  gnus-group-get-new-news(2)
  call-interactively(gnus-group-get-new-news)

Anyone's got an idea what is wrong?

Re: denying nnimap server causes nnimap-close-group to crash

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

> Platform: Gnus v5.8.7, XEmacs 20.4, linux
> When I'm at home, none of the IMAP servers at work are available, so I 
> would like to deny them.

> However if I go to the server buffer, and press D on these servers,
> and then go back to *Group* and press 
> 	g
> I end up with the following stack trace:

> Signaling: (wrong-type-argument stringp nil)
>   set-buffer(nil)
>   (save-current-buffer (set-buffer nnimap-server-buffer) (when (and ... ...) (case nnimap-expunge-on-close ... ... ...) (not imap-current-mailbox)))
> )
>   (with-current-buffer nnimap-server-buffer (when (and ... ...) (case nnimap-expunge-on-close ... ... ...) (not imap-current-mailbox)))
> )
>   nnimap-close-group("INBOX" "somemachine.somecompany.no")
>   gnus-get-unread-articles(2)
>   gnus-group-get-new-news(2)
>   call-interactively(gnus-group-get-new-news)

Further datapoint: If an nnimap server ends up as denied because of a
timeout or a C-g while Gnus is trying to access it, the error above
doesn't occur.

Re: denying nnimap server causes nnimap-close-group to crash

[Simon Josefsson]

Steinar Bang <sb@metis.no> writes:

> However if I go to the server buffer, and press D on these servers,
> and then go back to *Group* and press 
> 	g
> I end up with the following stack trace:
> 
> Signaling: (wrong-type-argument stringp nil)
>   set-buffer(nil)
>   (save-current-buffer (set-buffer nnimap-server-buffer) (when (and ... ...) (case nnimap-expunge-on-close ... ... ...) (not imap-current-mailbox)))
> )
>   (with-current-buffer nnimap-server-buffer (when (and ... ...) (case nnimap-expunge-on-close ... ... ...) (not imap-current-mailbox)))
> )
>   nnimap-close-group("INBOX" "somemachine.somecompany.no")
>   gnus-get-unread-articles(2)
>   gnus-group-get-new-news(2)
>   call-interactively(gnus-group-get-new-news)
> 
> Anyone's got an idea what is wrong?

Looks like `gnus-get-unread-articles' doesn't care if a server is
denied or not.  Could you try this patch?

2000-05-30  Simon Josefsson  <jas@pdc.kth.se>

	* gnus-start.el (gnus-get-unread-articles): If
	`gnus-activate-group' and/or `gnus-check-server' return nil, don't
	try to do anything on that server.

Index: gnus-start.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus-start.el,v
retrieving revision 5.54
diff -w -u -u -w -r5.54 gnus-start.el
--- gnus-start.el	2000/05/23 08:09:24	5.54
+++ gnus-start.el	2000/05/29 12:00:19
@@ -1523,8 +1523,8 @@
 		       (setq method (gnus-server-get-method nil method)))))
 	       (not (gnus-secondary-method-p method)))
 	  ;; These groups are foreign.  Check the level.
-	  (when (<= (gnus-info-level info) foreign-level)
-	    (setq active (gnus-activate-group group 'scan))
+	  (when (and (<= (gnus-info-level info) foreign-level)
+                     (setq active (gnus-activate-group group 'scan)))
 	    ;; Let the Gnus agent save the active file.
 	    (when (and gnus-agent gnus-plugged active)
 	      (gnus-agent-save-group-info
@@ -1565,7 +1565,8 @@
 		(setq active (gnus-activate-group group))
 	      (setq active (gnus-activate-group group 'scan))
 	      (push method scanned-methods))
-	    (inline (gnus-close-group group))))))
+            (when active
+              (gnus-close-group group))))))
 
       ;; Get the number of unread articles in the group.
       (cond
@@ -1587,7 +1588,7 @@
       (let* ((mg (pop retrievegroups))
 	     (method (or (car mg) gnus-select-method))
 	     (groups (cdr mg)))
-	(gnus-check-server method)
+	(when (gnus-check-server method)
 	;; Request that the backend scan its incoming messages.
 	(when (gnus-check-backend-function 'request-scan (car method))
 	  (gnus-request-scan nil method))
@@ -1603,7 +1604,7 @@
 	    ;; The group couldn't be reached, so we nix out the number of
 	    ;; unread articles and stuff.
 	    (gnus-set-active group nil)
-	    (setcar (gnus-gethash group gnus-newsrc-hashtb) t))))))
+              (setcar (gnus-gethash group gnus-newsrc-hashtb) t)))))))
 
     (gnus-message 5 "Checking new news...done")))
 

Re: denying nnimap server causes nnimap-close-group to crash

[Steinar Bang]

>>>>> Simon Josefsson <jas@pdc.kth.se>:

> Looks like `gnus-get-unread-articles' doesn't care if a server is
> denied or not.  Could you try this patch?

> 2000-05-30  Simon Josefsson  <jas@pdc.kth.se>

> 	* gnus-start.el (gnus-get-unread-articles): If
> 	`gnus-activate-group' and/or `gnus-check-server' return nil, don't
> 	try to do anything on that server.

That worked fine!  When the nnimap servers are denied, I can do a normal
	g
command without any error messages, and when I go unplugged and open
the servers, I can access the articles cached by agent.

Would it be possible to make Gnus open agentized denied servers in the 
unplugged state, without having to open the servers in the server
buffer? 

Re: denying nnimap server causes nnimap-close-group to crash

[Simon Josefsson]

Steinar Bang <sb@metis.no> writes:

> That worked fine!

Ok, commited.  Hope it doesn't cause other problems...

> Would it be possible to make Gnus open agentized denied servers in the 
> unplugged state, without having to open the servers in the server
> buffer? 

Wouldn't that be kind of unexpected?  If you tell Gnus the server is
denied, you'd expect it to remain denied, wouldn't you?

Re: denying nnimap server causes nnimap-close-group to crash

[Steinar Bang]

>>>>> Simon Josefsson <jas@pdc.kth.se>:

> Steinar Bang <sb@metis.no> writes:

>> Would it be possible to make Gnus open agentized denied servers in
>> the unplugged state, without having to open the servers in the
>> server buffer?

> Wouldn't that be kind of unexpected?  If you tell Gnus the server is
> denied, you'd expect it to remain denied, wouldn't you?

I didn't.  I expected "denied" to deal with network traffic, and I
expected to be able to read agent-cached articles in unplugged mode
for groups belonging to these servers.

Re: denying nnimap server causes nnimap-close-group to crash

[Christoph Rohland]

Steinar Bang <sb@metis.no> writes:

> >>>>> Simon Josefsson <jas@pdc.kth.se>:
> 
> > Steinar Bang <sb@metis.no> writes:
> 
> >> Would it be possible to make Gnus open agentized denied servers in
> >> the unplugged state, without having to open the servers in the
> >> server buffer?
> 
> > Wouldn't that be kind of unexpected?  If you tell Gnus the server is
> > denied, you'd expect it to remain denied, wouldn't you?
> 
> I didn't.  I expected "denied" to deal with network traffic, and I
> expected to be able to read agent-cached articles in unplugged mode
> for groups belonging to these servers.

I second that. The expected behaviour of a failed connection tothe
server should be: 'I give you as much as I have' instead of 'I simply
deniy acces'. perhaps we need another state for failed connects
instead of 'denied'.

Greetings
		Christoph

Re: denying nnimap server causes nnimap-close-group to crash

[Toby Speight]

CR> Christoph Rohland <URL:mailto:cr@sap.com>

0> In article <qwwbt1kxkhb.fsf@sap.com>,
0> CR wrote:

CR> The expected behaviour of a failed connection tothe server should
CR> be: 'I give you as much as I have' instead of 'I simply deniy
CR> acces'.  perhaps we need another state for failed connects instead
CR> of 'denied'.

This would be useful - but I wouldn't want it to depend on the Agent,
not being an Agent user.  (I'd like to be able to easily read cached
articles on denied servers).