Pronews/2: Phantom unread
John Small
mozilla.support.firefox, has started showing a significant number of
unread messages. (As I write this the count is 81.)
But I cannot find these messages. The F4 or F8 keys cannot find them
either.
I do have one global filter but it is hard to believe that, all of a
sudden, the poster being filtered posted 81 messages to this group. (I
will not name names but the filter on one of those morons who lurk in
OS/2-related groups making a severe pain of themselves. This is why I
doubt that 81 messages from the idiot, all of a sudden, in a non-OS/2
group.) The filter is supposed to mark the messages as read which is
another reason I do not think the filter is the reason.
Is there some way to figure out where these phantom messages are?
Thanks.
--
John Small
Trevor Hemsley
<jsm...@os2world.net> wrote:
> I am using Pronews/2 1.60 cp125. And recently one of my news groups,
> mozilla.support.firefox, has started showing a significant number of
> unread messages. (As I write this the count is 81.)
81 out of how many?
> But I cannot find these messages. The F4 or F8 keys cannot find them
> either.
Not the first time I've heard of a problem like this.
> I do have one global filter but it is hard to believe that, all of a
> sudden, the poster being filtered posted 81 messages to this group. (I
> will not name names but the filter on one of those morons who lurk in
> OS/2-related groups making a severe pain of themselves. This is why I
> doubt that 81 messages from the idiot, all of a sudden, in a non-OS/2
> group.) The filter is supposed to mark the messages as read which is
> another reason I do not think the filter is the reason.
>
> Is there some way to figure out where these phantom messages are?
Depends on how big the group is and how long you want to spend tracking it down.
If you drop to a command prompt and cd to your \pronews directory and run
showhead /all mozilla.support.firefox | less
then it will dump a listing of every article in the group. When I subscribed to
that group it told me that it had 103,000+ posts so that method might take a
while :-(
--
Trevor Hemsley, Brighton, UK
Trevor dot Hemsley at ntlworld dot com
Trevor Hemsley
<jsm...@os2world.net> wrote:
> I am using Pronews/2 1.60 cp125. And recently one of my news groups,
> mozilla.support.firefox, has started showing a significant number of
> unread messages. (As I write this the count is 81.)
Yep, I can recreate this now. I subscribed to the group and downloaded all
headers, opened the group, highlighted the whole lot and marked them all as
read. It then said I had 85 unread articles. Closed and opened the group and saw
3 had mysteriously appeared and marked those as read too. No change on closing
and reopening now. Still 82 unread. Open group, open group settings, check the
"Don't thread headers" option and then apply and the missing posts all appear.
I'm looking further but a quick guess says that there are duplicate message-ids
in there. I'm about to download the lot again and then I can check that theory.
Good news, none of the articles that were missing looked particularly exciting
:-)
Trevor Hemsley
<jsm...@os2world.net> wrote:
> I am using Pronews/2 1.60 cp125. And recently one of my news groups,
> mozilla.support.firefox, has started showing a significant number of
> unread messages. (As I write this the count is 81.)
There are messages in that group with invalid Message-ID headers. The RFC says
The "Message-ID" line gives the message a unique identifier. The
Message-ID may not be reused during the lifetime of any previous
message with the same Message-ID. (It is recommended that no
Message-ID be reused for at least two years.) Message-ID's have the
syntax:
<string not containing blank or ">">
In order to conform to RFC-822, the Message-ID must have the format:
<unique@full_domain_name>
where full_domain_name is the full name of the host at which the
message entered the network, including a domain that host is in, and
unique is any string of printing ASCII characters, not including "<"
(left angle bracket), ">" (right angle bracket), or "@" (at sign).
This group has a number of messages that have IDs that do not use that criteria.
Specifically the unique part of the ID is not unique. Like
<_@Jeff_Relf.Seattle.2009_Jul14.6.30am.tG> has a 'unique' portion which is
always "_".
All of the articles that are missing are either articles with duplicate IDs like
this or ones that are replies to them.
I'll need to look at the logic here to work out how to fix this but this is an
enormously complicated bit of code that was designed to be fast in execution (it
replaced a bit of code that worked perfectly but took an exponential amount of
time to execute depending on the number of articles in the group and made it
unusable once a group had more than about 20,000 articles).
Trevor Hemsley
<jsm...@os2world.net> wrote:
> I am using Pronews/2 1.60 cp125. And recently one of my news groups,
> mozilla.support.firefox, has started showing a significant number of
> unread messages. (As I write this the count is 81.)
The cleanest way I can find to fix this problem is to extend the portion of the
Message-ID field that Pronews uses to include all of it instead of just that
portion that is designated as being unique in the RFC. This does seem to fix the
problem for this group but... it has knock on effects.
1st - it takes a reload of the contents of the group to fix an existing group
that already have the problem
2nd - on groups that don't have the problem, unless you reload the group then
newly fetched articles will not be appended to the correct threads in the group.
Basically this amounts to saying "apply this fix only if you are prepared to
reload the contents of all your currently subscribed newsgroups". I'm not sure I
want to put out an update with this degree of requirement. Anyone else care to
comment on this?
Mark Dodel
<Trevor....@mytrousers.ntlworld.com> wrote:
-> On Sat, 18 Jul 2009 10:42:19 UTC in comp.os.os2.mail-news, "John Small"
-> <jsm...@os2world.net> wrote:
->
-> > I am using Pronews/2 1.60 cp125. And recently one of my news groups,
-> > mozilla.support.firefox, has started showing a significant number of
-> > unread messages. (As I write this the count is 81.)
->
-> The cleanest way I can find to fix this problem is to extend the portion of the
-> Message-ID field that Pronews uses to include all of it instead of just that
-> portion that is designated as being unique in the RFC. This does seem to fix the
-> problem for this group but... it has knock on effects.
->
-> 1st - it takes a reload of the contents of the group to fix an existing group
-> that already have the problem
-> 2nd - on groups that don't have the problem, unless you reload the group then
-> newly fetched articles will not be appended to the correct threads in the group.
->
-> Basically this amounts to saying "apply this fix only if you are prepared to
-> reload the contents of all your currently subscribed newsgroups". I'm not sure I
-> want to put out an update with this degree of requirement. Anyone else care to
-> comment on this?
->
I think this is the same problem I have with comp.os.linux.advocacy
where for the past several weeks I have always had 14 unread even
after marking all read in the group. I've had this problem at least
once before and fixed it by unsubscribing and re-subscribing, but that
doesn't sound like the problem you describe.
Mark
--
From the eComStation of Mark Dodel
Warpstock 2008 - Santa Cruz, California: http://www.warpstock.org
Warpstock Europe 2008 - D�sseldorf, Germany: http://www.warpstock.eu
Trevor Hemsley
<madode...@ptd.net> wrote:
> I think this is the same problem I have with comp.os.linux.advocacy
> where for the past several weeks I have always had 14 unread even
> after marking all read in the group. I've had this problem at least
> once before and fixed it by unsubscribing and re-subscribing, but that
> doesn't sound like the problem you describe.
You can list the articles that are unread but missing by running
showhead /all comp.os.linux.advocacy | grep -v 00000004
or just by changing the group from threaded to unthreaded mode. I'd be
interested in a mail showing me the showhead | grep -v output (as an attachment
cos it'll wrap wildly otherwise).
Ken Whiton
*-* In Article gjxI70UYBlcC-p...@trevor2.dsl.pipex.com,
*-* Trevor Hemsley wrote
*-* About Re: Pronews/2: Phantom unread
> <unique@full_domain_name>
They're not really "duplicates" either, because the
full_domain_name portions are different. Each one includes the date
and time the post was made, so his are "unique" on the wrong side of
the @ sign. :-(
The guy is a troll who has been disrupting several of the
mozilla.* newsgroups for the past few days. He uses a roll-his-own
newsreader and among other things has been "lecturing" several people
in the mozilla.support.thunderbird group on the content and use of
various RFCs. From what you say, he doesn't practice what he preaches
when it comes to his own reader.
Ken Whiton
--
FIDO: 1:132/152
InterNet: kenw...@surfglobal.net.INVAL (remove the obvious to reply)
John Small
<Trevor....@mytrousers.ntlworld.com> wrote:
This sounds like a lot of effort for both of us.
If I understand it correctly, this happens when the RFC regarding
unique ID's is violated, probably by other faulty newsreader software.
If this is correct, then I'm inclined to say "don't bother". I don't
mind missing articales posted with faulty software as long as it
remains a small percentage of the total. And I'd rather deal with the
annoyance of the non-zero unread count than reload all my groups. (Of
my opinion could change if these faulty ID's become pervasive.)
I have Pronews/2 set to purge articles with bodies after 60 days and
articles without bodies after 7 days. Does this mean that these
phantom unread articles will disappear after this time? (I understand
that new ones may appear if they, too, have faulty ID's.)
Thank you for your efforts in looking into this!
--
John Small
Trevor Hemsley
<jsm...@os2world.net> wrote:
> If I understand it correctly, this happens when the RFC regarding
> unique ID's is violated, probably by other faulty newsreader software.
> If this is correct, then I'm inclined to say "don't bother". I don't
> mind missing articales posted with faulty software as long as it
> remains a small percentage of the total. And I'd rather deal with the
> annoyance of the non-zero unread count than reload all my groups. (Of
> my opinion could change if these faulty ID's become pervasive.)
I've thought of a 3rd option. If I add a little code that checks for a new
option I can make the uniqueness check optional and default it to the current
behaviour. Setting the option will make it check the entire Message-ID field for
uniqueness and require the reload to work properly.
> I have Pronews/2 set to purge articles with bodies after 60 days and
> articles without bodies after 7 days. Does this mean that these
> phantom unread articles will disappear after this time? (I understand
> that new ones may appear if they, too, have faulty ID's.)
The only thing affected by this should the the threaded view of the newsgroup so
purging should kill them off.
Mark Dodel
<Trevor....@mytrousers.ntlworld.com> wrote:
-> On Sun, 19 Jul 2009 00:30:49 UTC in comp.os.os2.mail-news, "Mark Dodel"
-> <madode...@ptd.net> wrote:
->
-> > I think this is the same problem I have with comp.os.linux.advocacy
-> > where for the past several weeks I have always had 14 unread even
-> > after marking all read in the group. I've had this problem at least
-> > once before and fixed it by unsubscribing and re-subscribing, but that
-> > doesn't sound like the problem you describe.
->
-> You can list the articles that are unread but missing by running
->
-> showhead /all comp.os.linux.advocacy | grep -v 00000004
->
-> or just by changing the group from threaded to unthreaded mode. I'd be
-> interested in a mail showing me the showhead | grep -v output (as an attachment
-> cos it'll wrap wildly otherwise).
->
The problem disappeared on its own so I am unable to try this. I've
never seen it go away before. Always I have had to unsubscribe and
resubscribe. If it occurs again I will try this.