After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 400814 - [svn] unable to mark some groups as read
[svn] unable to mark some groups as read
Status: RESOLVED FIXED
Product: Pan
Classification: Other
Component: general
pre-1.0 betas
Other All
: Normal major
: 1.0
Assigned To: Charles Kerr
Pan QA Team
Depends on:
Blocks:
 
 
Reported: 2007-01-25 22:35 UTC by Christophe Lambin
Modified: 2007-01-31 16:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
keep headers and xov files in sync: whenever a group's headers are saved, save the xov file too. (762 bytes, patch)
2007-01-26 03:37 UTC, Charles Kerr
committed Details | Review

Description Christophe Lambin 2007-01-25 22:35:28 UTC
Please describe the problem:
Since a couple of days, the cvs^H^H^Hsvn-version doesn't mark certain groups as read.

What happens is:
- hit <ctrl>-<shift>-<n>
- unread count in grouplist is clear (and font goes to normal)
- but ... the articlelist continues to show unread articles
- switch out of group and back in
- articles are still unread and grouplist shows unread messages again.


Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Charles Kerr 2007-01-26 03:09:59 UTC
Breadcrumbs:

One article that didn't get marked as read has this Xref header:

   Xref: Hurricane-Charley alt.religion.kibology:136889


But the newsrc files look like this:

  newsrc-cox-east:alt.religion.kibology: 0-136866
  newsrc-cox-west:alt.religion.kibology: 0-136866,136872,137187,137599

For some reason there are articles outside of the `mark all read' range.
I don't know yet if that's an error in the code that marks the range, or
that remembers what the high range is.
Comment 2 Charles Kerr 2007-01-26 03:17:55 UTC
More breadcrumbs:

It _doesn't_ appear when you clear out all the group's stats,
fetch some headers, and then mark them read.  So maybe the
problem is when new headers are fetched, the group's high
mark isn't updated correctly... 
Comment 3 Charles Kerr 2007-01-26 03:19:25 UTC
On exiting after fetching a group's headers for the first time,
the correct information is written into newsgroups.xov.
Comment 4 Charles Kerr 2007-01-26 03:29:46 UTC
Theory: have you recently had a Pan session and fetched headers,
but then killed / ctrl-c'ed Pan instead of exiting it properly?
I know I have while debugging, and that could cause this problem --
the .xov file that holds the xover ranges is written when Pan 
shuts down, but the headers are saved to disk when you exit that group.

If you've had similar Pan sessions, we can plug that particular cause
for this bug by saving the .xov file ever time a group's headers are
saved.  This isn't expensive, so IMO it's a good thing anyway.
Then we can see if the problem persists.

If you haven't have similar Pan sessions, then we'll have to think
about this some more. =)
Comment 5 Charles Kerr 2007-01-26 03:37:45 UTC
Created attachment 81246 [details] [review]
keep headers and xov files in sync: whenever a group's headers are saved, save the xov file too.

Give this a spin and let me know.  I'll be using it too.

This won't actually fix anything that's already out of sync,
so the first thing to do to any given group is to resync by
fetching new headers.  Interesting errors are the ones that
show up after resynching.
Comment 6 Christophe Lambin 2007-01-26 22:30:05 UTC
I don't recall killing/ctrl-c'ing in the recent past, but I'll apply this patch and keep an eye on it.
Comment 7 Charles Kerr 2007-01-29 16:11:24 UTC
Chris: how's the patch working for you?
Comment 8 Christophe Lambin 2007-01-30 22:39:02 UTC
Haven't noticed any side effects with this patch. 

As you predicted, getting new headers did resync the group, so I think we're seeing the same bug.
Comment 9 Charles Kerr 2007-01-31 16:23:22 UTC
Committed to svn revision 137.