From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/38092 Path: main.gmane.org!not-for-mail From: Daniel Pittman Newsgroups: gmane.emacs.gnus.general Subject: Problems with .newsrc.eld (aws: Re: self-contained nnml) Date: Mon, 20 Aug 2001 12:35:13 +1000 Organization: Not today, thank you, Mother. Message-ID: <871ym7tq5a.fsf_-_@inanna.rimspace.net> References: <87itfkvac5.fsf@inanna.rimspace.net> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035173727 18993 80.91.224.250 (21 Oct 2002 04:15:27 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 04:15:27 +0000 (UTC) Return-Path: Return-Path: Original-Received: (qmail 23741 invoked from network); 20 Aug 2001 02:36:03 -0000 Original-Received: from melancholia.rimspace.net (HELO melancholia.danann.net) (203.36.211.210) by gnus.org with SMTP; 20 Aug 2001 02:36:03 -0000 Original-Received: from localhost (melancholia.rimspace.net [203.36.211.210]) by melancholia.danann.net (Postfix) with ESMTP id 2B8C22A836 for ; Mon, 20 Aug 2001 12:35:45 +1000 (EST) Original-Received: by localhost (Postfix, from userid 1000) id 702908208E; Mon, 20 Aug 2001 12:35:13 +1000 (EST) Original-To: ding@gnus.org In-Reply-To: (Simon Josefsson's message of "Sun, 19 Aug 2001 11:44:39 +0200") X-Homepage: http://danann.net/ User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (artichoke) Original-Lines: 113 Xref: main.gmane.org gmane.emacs.gnus.general:38092 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:38092 On Sun, 19 Aug 2001, Simon Josefsson wrote: > Daniel Pittman writes: > >> Recompile, yada, yada, then we boot XEmacs and it starts Gnus... >> >> ...the bootstrapping of the NNML marks works just fine. > > Does the .marks file contain correct marks for the nnml groups? > (If so, backup them now :-)) Yeah, it's got the right values and all. So does my .newsrc.eld What isn't right is that .newsrc.eld has the wrong number in the first field of the record for each group, such that: ("Inbox.stats.mail" 3 ((1 . 34)) nil nil ((timestamp 15232 18635))) The 3 there just after the group name seems to be what's causing the problems; that's the number of items shown for each group in the *Groups* buffer... >> Then I note that the summary buffer is ... odd. The majority of my >> groups seem to have three articles in them now, which is odd, given >> the standard set is > 2000 for most of them. > > What does `G E' on the group show? Does `g' or `M-g' change anything? G E shows what I expect, the correct information, save for the 3 as shown in the record above. `g' will bring all the groups back into sync with what .newsrc.eld shows for total number of messages, 3. Every NNML shows this result when I hit `g', as it applies the same operation to them all. `M-g' makes the individual groups work correctly. They show the correct number of unread messages, as they did before, as well as showing the correct total number. The groups also work after `M-g' is hit, but don't when `g' is hit. That is, I can enter the group, modify it, etc, and it works correctly. > Does the .marks file contain exactly the same marks as `G E'? Yes, with the exception of adding `read' to the start of the read field, which isn't present in .newsrc.eld, and *not* featuring the magic number 3 anywhere in the record. I presume both these differences are by design, though, but include the record for the group above for comparison: ((read (1 . 3))) [...] > So, to get this right, it says 1/3 in the group buffer, you press RET > and you don't get a summary buffer and now it says 0/3. Did I > understand you correctly? Yes. That's exactly the observed behavior. > What was the error message you got when trying to enter the group? Nothing. Not a single error, not a log message, not a tittle or jot. I have `gnus-verbose' set to 7. >> So, I make the last test and 'g' in the groups buffer, which restores >> the system message to life. Ugh. > > It says 1/3 in the group buffer again? Entering the summary buffer > still doesn't work? Yes, that's correct. > Do you have more than one nnml server, btw? No. > Could you edebug `nnml-request-update-info'? Especially compare the > `info' on input with how it looks when the function is about to > terminate. That's all correct. The issue is that when using `g', rather than `M-g', this function gets 3 passed in as the, er, second value of the INFO argument. This is identical when it's called through the path of `g' or `M-g'. The marks are correct in either case. > I committed some fixes, one of them may make a difference so please > try latest CVS first. This is identical with a CVS update from this morning. :/ > Weird, I can't trigger this at all. It just works. But I only have > one test nnml server. Maybe there's a proble if you have more than > one nnml server. *sigh* No, only the one server. I think that my .newsrc.eld got corrupted somewhere along the way but, due to some glitch in the system previously, I never saw that result. This would work if something has changed recently so that NNML no longer takes identical paths for `g' and `M-g' to find the total number of articles... Suggestions on how to fix this, anyone? Daniel -- When the state is most corrupt, then the laws are most multiplied. -- Tacitus