Gnus losing information about what has been read

Gnus losing information about what has been read

[Jan Rychter]

Ok. My Gnus has just forgotten which articles I have read in some
groups. Again. I have long had the impression that it does that behind
my back sometimes, but I was never sure enough. This time I'm quite
sure, because it has forgotten about roughly 1k articles.

This seems to happen for me in agentized groups that I read while
unplugged -- after I go online again, the articles are visible as
"unread", again.

I'm using No Gnus 0.3, updated from CVS on Aug 5, under XEmacs -- but
I'm quite sure the problem has been there for quite some time.

Any ideas?

--J.

Re: Gnus losing information about what has been read

[Jan Rychter]

[Quoting my post from about 2 weeks ago...]
>>>>> "Jan" == Jan Rychter <jan@rychter.com> writes:
 Jan> Ok. My Gnus has just forgotten which articles I have read in some
 Jan> groups. Again. I have long had the impression that it does that
 Jan> behind my back sometimes, but I was never sure enough. This time
 Jan> I'm quite sure, because it has forgotten about roughly 1k
 Jan> articles.

 Jan> This seems to happen for me in agentized groups that I read while
 Jan> unplugged -- after I go online again, the articles are visible as
 Jan> "unread", again.

 Jan> I'm using No Gnus 0.3, updated from CVS on Aug 5, under XEmacs --
 Jan> but I'm quite sure the problem has been there for quite some time.

 Jan> Any ideas?

I am rather alarmed by the number of responses to this report -- namely:
zero.

Am I the only one who sees that?

Could it be related to marks synchronization with the server, which Gnus
prompts me for?

--J.

Re: Gnus losing information about what has been read

[Jonas Steverud]

Jan Rychter <jan@rychter.com> writes:

> Am I the only one who sees that?

No, I saw it too. :-) But I have no idea of how to help. Sorry. Try to
post relevant parts of .emacs/.gnus. Questions about the agent,
similar to this, seems to be quite frequent, why not try to search the
archives at gmane?

Besides, are your newsserver reliable? The one I used before had a
habit of reporting all articles new on a weekly basis (it was a *very*
badly admin:ed server run by my ISP and it was a good thing they
closed it down). I used the caching feature to get around this problem
but I've never used the agent. Do you see the problem with other
newsreaders?  Or if you don't use the agent but reads online for a
while?

HTH!

-- 
(        http://hem.bredband.net/steverud/        !     Wei Wu Wei     )
(        Meaning of U2 Lyrics, Roleplaying        !  To Do Without Do  )

Re: Gnus losing information about what has been read

[Jan Rychter]

>>>>> "Jonas" == Jonas Steverud <tvrud@bredband.net> writes:
 Jonas> Jan Rychter <jan@rychter.com> writes:
 >> Am I the only one who sees that?

[...]

 Jonas> Besides, are your newsserver reliable? The one I used before had
 Jonas> a habit of reporting all articles new on a weekly basis (it was
 Jonas> a *very* badly admin:ed server run by my ISP and it was a good
 Jonas> thing they closed it down). I used the caching feature to get
 Jonas> around this problem but I've never used the agent. Do you see
 Jonas> the problem with other newsreaders?  Or if you don't use the
 Jonas> agent but reads online for a while?

This happens for me with three news servers, one of them being
news.gmane.org. I think it only happens if I read news while unplugged.

--J.

Re: Gnus losing information about what has been read

[Xavier Maillard]

On 22 sep 2004, Jan Rychter wrote:

> > > > > > "Jonas" == Jonas Steverud <tvrud@bredband.net>
> > > > > > writes:
> Jonas> Jan Rychter <jan@rychter.com> writes:
> > > Am I the only one who sees that?
> 
> [...]
> 
> Jonas> Besides, are your newsserver reliable? The one I used
> Jonas> before had a habit of reporting all articles new on a
> Jonas> weekly basis (it was a *very* badly admin:ed server run
> Jonas> by my ISP and it was a good thing they closed it down).
> Jonas> I used the caching feature to get around this problem
> Jonas> but I've never used the agent. Do you see the problem
> Jonas> with other newsreaders? Or if you don't use the agent
> Jonas> but reads online for a while?
> 
> This happens for me with three news servers, one of them being
> news.gmane.org. I think it only happens if I read news while
> unplugged.

Not only. I have the same problem with the 'J s' command in the
group buffer.

I have clue that there is a problem since, I fetched as usually
this morning my agentized server. When in the train I had tons of
articles (already read), downloaded again and marked as new !!

Note that I suspect this variable
gnus-agent-consider-all-articles to be source of some problems
but with no clue at all.

The docstring is obscur to me:

,----[ C-h v gnus-agent-consider-all-articles RET ]
| gnus-agent-consider-all-articles's value is nil
| 
| When non-nil, the agent will let the agent predicate decide
| whether articles need to be downloaded or not, for all articles.  When
| nil, the default, the agent will only let the predicate decide
| whether unread articles are downloaded or not.  If you enable this,
| groups with large active ranges may open slower and you may also want
| to look into the agent expiry settings to block the expiration of
| read articles as they would just be downloaded again.
| 
| You can customize this variable.
| 
| Defined in `gnus-agent'.
`----

My problem is that even switching it to t doesn't solve the problem...
-- 
      Xavier Maillard| "Stand Back! I'm a programmer!"
.0.             zedek@gnu-rox.orgz|
..0             (+33) 326 770 221 |   Webmaster, emacsfr.org
000              PGP : 0x1E028EA5 |    Membre de l' APRIL

Re: Gnus losing information about what has been read

[Ralf Angeli]

* Jan Rychter (2004-09-21) writes:

> [Quoting my post from about 2 weeks ago...]
>>>>>> "Jan" == Jan Rychter <jan@rychter.com> writes:
>  Jan> Ok. My Gnus has just forgotten which articles I have read in some
>  Jan> groups. Again. I have long had the impression that it does that
>  Jan> behind my back sometimes, but I was never sure enough. This time
>  Jan> I'm quite sure, because it has forgotten about roughly 1k
>  Jan> articles.
>
>  Jan> This seems to happen for me in agentized groups that I read while
>  Jan> unplugged -- after I go online again, the articles are visible as
>  Jan> "unread", again.
>
>  Jan> I'm using No Gnus 0.3, updated from CVS on Aug 5, under XEmacs --
>  Jan> but I'm quite sure the problem has been there for quite some time.
>
>  Jan> Any ideas?
>
> I am rather alarmed by the number of responses to this report -- namely:
> zero.
>
> Am I the only one who sees that?

I don't know exactly if it is the same problem, but for me Gnus
forgets marks with the following usage pattern:

When being online, start Gnus in "Plugged" state (`emacs -f gnus').
Download new (nntp) articles with `J s' into the agent.  Go into
"Unplugged" state with `J j'.  Read the new articles or mark them as
read, e.g. with `c y'.  Close Gnus with `q y' and close Emacs.  Start
Emacs/Gnus again in "Plugged" state.  The read articles will be marked
unread again.  (If it doesn't "work" the first time, maybe try the
pattern once again.)  One can distinguish read articles which are not
marked as read from really new articles.  The latter have an unseen
mark (`.') in the summary buffer.

Those problems started with the introduction of marks for nntp.

-- 
Ralf

Re: Gnus losing information about what has been read

[Kevin Greiner]

Ralf Angeli <dev.null@iwi.uni-sb.de> writes:

> * Jan Rychter (2004-09-21) writes:
>
>> [Quoting my post from about 2 weeks ago...]
>>>>>>> "Jan" == Jan Rychter <jan@rychter.com> writes:
>>  Jan> Ok. My Gnus has just forgotten which articles I have read in some
>>  Jan> groups. Again. I have long had the impression that it does that
>>  Jan> behind my back sometimes, but I was never sure enough. This time
>>  Jan> I'm quite sure, because it has forgotten about roughly 1k
>>  Jan> articles.
>>
>>  Jan> This seems to happen for me in agentized groups that I read while
>>  Jan> unplugged -- after I go online again, the articles are visible as
>>  Jan> "unread", again.
>>
>>  Jan> I'm using No Gnus 0.3, updated from CVS on Aug 5, under XEmacs --
>>  Jan> but I'm quite sure the problem has been there for quite some time.
>>
>>  Jan> Any ideas?
>>
>> I am rather alarmed by the number of responses to this report -- namely:
>> zero.
>>
>> Am I the only one who sees that?
>
> I don't know exactly if it is the same problem, but for me Gnus
> forgets marks with the following usage pattern:
>
> When being online, start Gnus in "Plugged" state (`emacs -f gnus').
> Download new (nntp) articles with `J s' into the agent.  Go into
> "Unplugged" state with `J j'.  Read the new articles or mark them as
> read, e.g. with `c y'.  Close Gnus with `q y' and close Emacs.  Start
> Emacs/Gnus again in "Plugged" state.  The read articles will be marked
> unread again.  (If it doesn't "work" the first time, maybe try the
> pattern once again.)  One can distinguish read articles which are not
> marked as read from really new articles.  The latter have an unseen
> mark (`.') in the summary buffer.
>
> Those problems started with the introduction of marks for nntp.

These problems occur because you are not sync'ing the marks that were
cached in the agent (while unplugged) when you next plug in.  What you
have to do is press 'J Y' in the group buffer BEFORE opening a summary
buffer.

If you don't want to do the 'J Y', update to "No Gnus 0.3, Sept 21".
I just checked in the patch to always bypass the agent when writing
nntp marks.

Kevin

Re: Gnus losing information about what has been read

[Ralf Angeli]

* Kevin Greiner (2004-09-22) writes:

> Ralf Angeli <dev.null@iwi.uni-sb.de> writes:
>
>> I don't know exactly if it is the same problem, but for me Gnus
>> forgets marks with the following usage pattern:
>>
>> When being online, start Gnus in "Plugged" state (`emacs -f gnus').
>> Download new (nntp) articles with `J s' into the agent.  Go into
>> "Unplugged" state with `J j'.  Read the new articles or mark them as
>> read, e.g. with `c y'.  Close Gnus with `q y' and close Emacs.  Start
>> Emacs/Gnus again in "Plugged" state.  The read articles will be marked
>> unread again.  (If it doesn't "work" the first time, maybe try the
>> pattern once again.)  One can distinguish read articles which are not
>> marked as read from really new articles.  The latter have an unseen
>> mark (`.') in the summary buffer.
>>
>> Those problems started with the introduction of marks for nntp.
>
> These problems occur because you are not sync'ing the marks that were
> cached in the agent (while unplugged) when you next plug in.  What you
> have to do is press 'J Y' in the group buffer BEFORE opening a summary
> buffer.
>
> If you don't want to do the 'J Y', update to "No Gnus 0.3, Sept 21".
> I just checked in the patch to always bypass the agent when writing
> nntp marks.

Hm, neither typing `J Y' nor using a fresh CVS checkout (I can see the
variable `gnus-servers-that-use-local-marks') make a difference here.

-- 
Ralf

Re: Gnus losing information about what has been read

[Kevin Greiner]

Ralf Angeli <dev.null@iwi.uni-sb.de> writes:

> * Kevin Greiner (2004-09-22) writes:
>
>> Ralf Angeli <dev.null@iwi.uni-sb.de> writes:
>>
>>> I don't know exactly if it is the same problem, but for me Gnus
>>> forgets marks with the following usage pattern:
>>>
>>> When being online, start Gnus in "Plugged" state (`emacs -f gnus').
>>> Download new (nntp) articles with `J s' into the agent.  Go into
>>> "Unplugged" state with `J j'.  Read the new articles or mark them as
>>> read, e.g. with `c y'.  Close Gnus with `q y' and close Emacs.  Start
>>> Emacs/Gnus again in "Plugged" state.  The read articles will be marked
>>> unread again.  (If it doesn't "work" the first time, maybe try the
>>> pattern once again.)  One can distinguish read articles which are not
>>> marked as read from really new articles.  The latter have an unseen
>>> mark (`.') in the summary buffer.
>>>
>>> Those problems started with the introduction of marks for nntp.
>>
>> These problems occur because you are not sync'ing the marks that were
>> cached in the agent (while unplugged) when you next plug in.  What you
>> have to do is press 'J Y' in the group buffer BEFORE opening a summary
>> buffer.
>>
>> If you don't want to do the 'J Y', update to "No Gnus 0.3, Sept 21".
>> I just checked in the patch to always bypass the agent when writing
>> nntp marks.
>
> Hm, neither typing `J Y' nor using a fresh CVS checkout (I can see the
> variable `gnus-servers-that-use-local-marks') make a difference here.

My patch was defective.  I had tested physical unplugging rather than
gnus "unplugged".  I've updated gnus-int.el again.

Kevin

Re: Gnus losing information about what has been read

[Ralf Angeli]

* Kevin Greiner (2004-09-23) writes:

> My patch was defective.  I had tested physical unplugging rather than
> gnus "unplugged".  I've updated gnus-int.el again.

Now the marks are updated correctly.  Thank you very much.

I don't know if it is related to your patch, but I get an error after
changing to "Unplugged" state, entering a group, reading some articles
and trying to leave the group with `q'.  Here is the backtrace:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  expand-file-name(nil "/home/angeli/News/marks/news.individual.net/de/comp/text/tex/")
  nntp-open-marks("de.comp.text.tex" "news.individual.net")
  nntp-request-set-mark("de.comp.text.tex" (((172683) add (read))) "news.individual.net")
  gnus-request-set-mark("nntp+news.individual.net:de.comp.text.tex" (((172683) add (read))))
  gnus-update-read-articles("nntp+news.individual.net:de.comp.text.tex" nil)
  gnus-summary-update-info()
  gnus-summary-exit()
  call-interactively(gnus-summary-exit)

Doing an `M-: (setq nntp-marks-file-name ".marks")' allows me to leave
the group again.

-- 
Ralf

Re: Gnus losing information about what has been read

[Kevin Greiner]

Ralf Angeli <dev.null@iwi.uni-sb.de> writes:

> * Kevin Greiner (2004-09-23) writes:
>
>> My patch was defective.  I had tested physical unplugging rather than
>> gnus "unplugged".  I've updated gnus-int.el again.
>
> Now the marks are updated correctly.  Thank you very much.
>
> I don't know if it is related to your patch, but I get an error after
> changing to "Unplugged" state, entering a group, reading some articles
> and trying to leave the group with `q'.  Here is the backtrace:
>
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   expand-file-name(nil "/home/angeli/News/marks/news.individual.net/de/comp/text/tex/")
>   nntp-open-marks("de.comp.text.tex" "news.individual.net")
>   nntp-request-set-mark("de.comp.text.tex" (((172683) add (read))) "news.individual.net")
>   gnus-request-set-mark("nntp+news.individual.net:de.comp.text.tex" (((172683) add (read))))
>   gnus-update-read-articles("nntp+news.individual.net:de.comp.text.tex" nil)
>   gnus-summary-update-info()
>   gnus-summary-exit()
>   call-interactively(gnus-summary-exit)
>
> Doing an `M-: (setq nntp-marks-file-name ".marks")' allows me to leave
> the group again.

It almost certainly is related.  I can not reproduce the problem using
the sequence provided.  Can you load the lisp files so that we get a
better stacktrace?  Just do the following before running gnus.

M-x load-library<ret>gnus-int.el<ret>
M-x load-library<ret>gnus-agent.el<ret>
M-x load-library<ret>nntp.el<ret>

Kevin

Re: Gnus losing information about what has been read

[Ralf Angeli]

* Kevin Greiner (2004-09-23) writes:

> Ralf Angeli <dev.null@iwi.uni-sb.de> writes:
>
>> I don't know if it is related to your patch, but I get an error after
>> changing to "Unplugged" state, entering a group, reading some articles
>> and trying to leave the group with `q'.  Here is the backtrace:
[...]
>> Doing an `M-: (setq nntp-marks-file-name ".marks")' allows me to leave
>> the group again.
>
> It almost certainly is related.  I can not reproduce the problem using
> the sequence provided.  Can you load the lisp files so that we get a
> better stacktrace?  Just do the following before running gnus.
>
> M-x load-library<ret>gnus-int.el<ret>
> M-x load-library<ret>gnus-agent.el<ret>
> M-x load-library<ret>nntp.el<ret>

Okay, here it is:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  expand-file-name(nil "/home/angeli/News/marks/news.individual.net/de/comp/text/tex/")
  (let ((file ...)) (if (file-exists-p file) (condition-case err ... ...) (let ... ... ... ... ... ... ...)))
  nntp-open-marks("de.comp.text.tex" "news.individual.net")
  (if nntp-marks-is-evil nil (nntp-possibly-create-directory group server) (nntp-open-marks group server) (dolist (action actions) (let ... ... ...)) (nntp-save-marks group server))
  (unless nntp-marks-is-evil (nntp-possibly-create-directory group server) (nntp-open-marks group server) (dolist (action actions) (let ... ... ...)) (nntp-save-marks group server))
  nntp-request-set-mark("de.comp.text.tex" (((172736) add (read))) "news.individual.net")
  funcall(nntp-request-set-mark "de.comp.text.tex" (((172736) add (read))) "news.individual.net")
  (if (not (gnus-check-backend-function ... ...)) action (funcall (gnus-get-function gnus-command-method ...) (gnus-group-real-name group) action (nth 1 gnus-command-method)))
  (let* ((gnus-command-method ...) (gnus-agent ...)) (if (not ...) action (funcall ... ... action ...)))
  gnus-request-set-mark("nntp+news.individual.net:de.comp.text.tex" (((172736) add (read))))
  gnus-update-read-articles("nntp+news.individual.net:de.comp.text.tex" nil)
  gnus-summary-update-info()
  gnus-summary-exit()
  call-interactively(gnus-summary-exit)

I noticed that after starting Gnus, an `M-: nntp-marks-file-name RET'
returns ".marks".  But after switching to "Unplugged" state with `J j',
the same command returns nil.

-- 
Ralf

Re: Gnus losing information about what has been read

[Kevin Greiner]

Ralf Angeli <dev.null@iwi.uni-sb.de> writes:

> * Kevin Greiner (2004-09-23) writes:
>
>> Ralf Angeli <dev.null@iwi.uni-sb.de> writes:
>>
>>> I don't know if it is related to your patch, but I get an error after
>>> changing to "Unplugged" state, entering a group, reading some articles
>>> and trying to leave the group with `q'.  Here is the backtrace:
> [...]
>>> Doing an `M-: (setq nntp-marks-file-name ".marks")' allows me to leave
>>> the group again.
>>
>> It almost certainly is related.  I can not reproduce the problem using
>> the sequence provided.  Can you load the lisp files so that we get a
>> better stacktrace?  Just do the following before running gnus.
>>
>> M-x load-library<ret>gnus-int.el<ret>
>> M-x load-library<ret>gnus-agent.el<ret>
>> M-x load-library<ret>nntp.el<ret>
>
> Okay, here it is:
>
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   expand-file-name(nil "/home/angeli/News/marks/news.individual.net/de/comp/text/tex/")
>   (let ((file ...)) (if (file-exists-p file) (condition-case err ... ...) (let ... ... ... ... ... ... ...)))
>   nntp-open-marks("de.comp.text.tex" "news.individual.net")
>   (if nntp-marks-is-evil nil (nntp-possibly-create-directory group server) (nntp-open-marks group server) (dolist (action actions) (let ... ... ...)) (nntp-save-marks group server))
>   (unless nntp-marks-is-evil (nntp-possibly-create-directory group server) (nntp-open-marks group server) (dolist (action actions) (let ... ... ...)) (nntp-save-marks group server))
>   nntp-request-set-mark("de.comp.text.tex" (((172736) add (read))) "news.individual.net")
>   funcall(nntp-request-set-mark "de.comp.text.tex" (((172736) add (read))) "news.individual.net")
>   (if (not (gnus-check-backend-function ... ...)) action (funcall (gnus-get-function gnus-command-method ...) (gnus-group-real-name group) action (nth 1 gnus-command-method)))
>   (let* ((gnus-command-method ...) (gnus-agent ...)) (if (not ...) action (funcall ... ... action ...)))
>   gnus-request-set-mark("nntp+news.individual.net:de.comp.text.tex" (((172736) add (read))))
>   gnus-update-read-articles("nntp+news.individual.net:de.comp.text.tex" nil)
>   gnus-summary-update-info()
>   gnus-summary-exit()
>   call-interactively(gnus-summary-exit)
>
> I noticed that after starting Gnus, an `M-: nntp-marks-file-name RET'
> returns ".marks".  But after switching to "Unplugged" state with `J j',
> the same command returns nil.
>

I'm trying an entirely different aproach now as it turned out that the
nntp implementation required the server to be open for
nntp-marks-file-name to be correct.

It appears that the agent's synchronization function could actually
try to write the flags back to itself. Then, having done so, delete
the flags file so that all of the flags were lost.  I've added some
additional checks.  Please give it a try.

Kevin

Re: Gnus losing information about what has been read

[Ralf Angeli]

* Kevin Greiner (2004-09-24) writes:

> I'm trying an entirely different aproach now as it turned out that the
> nntp implementation required the server to be open for
> nntp-marks-file-name to be correct.
>
> It appears that the agent's synchronization function could actually
> try to write the flags back to itself. Then, having done so, delete
> the flags file so that all of the flags were lost.  I've added some
> additional checks.  Please give it a try.

After a fresh CVS checkout I don't get the error related to
`nntp-marks-file-name' being nil anymore.  I noticed a message in the
echo area upon leaving a group in unplugged state with e.g. `q':

Added to /home/angeli/News/agent/nntp/news.gmane.org/agent.lib/flags

While there are no errors anymore, the marks are forgotten again.
Tested this by starting Emacs/Gnus in plugged state, downloading new
articles into the agent with `J s', switching to unplugged state with
`J j', reading the articles, shutting down Gnus in unplugged state
with `q y' and restarting Emacs and Gnus in plugged state.

-- 
Ralf

Re: Gnus losing information about what has been read

[Kevin Greiner]

Ralf Angeli <dev.null@iwi.uni-sb.de> writes:

> * Kevin Greiner (2004-09-24) writes:
>
>> I'm trying an entirely different aproach now as it turned out that the
>> nntp implementation required the server to be open for
>> nntp-marks-file-name to be correct.
>>
>> It appears that the agent's synchronization function could actually
>> try to write the flags back to itself. Then, having done so, delete
>> the flags file so that all of the flags were lost.  I've added some
>> additional checks.  Please give it a try.
>
> After a fresh CVS checkout I don't get the error related to
> `nntp-marks-file-name' being nil anymore.  I noticed a message in the
> echo area upon leaving a group in unplugged state with e.g. `q':
>
> Added to /home/angeli/News/agent/nntp/news.gmane.org/agent.lib/flags
>
> While there are no errors anymore, the marks are forgotten again.
> Tested this by starting Emacs/Gnus in plugged state, downloading new
> articles into the agent with `J s', switching to unplugged state with
> `J j', reading the articles, shutting down Gnus in unplugged state
> with `q y' and restarting Emacs and Gnus in plugged state.

Have you customized gnus-agent-synchronize-flags?  If it is null,
automatic synchronization will be completely turned off.

From this description, the unplugged flags are being saved but never
sync'ed.  In the last step, when you restart emacs and gnus in a
plugged state, do you automatically perform a fetch session ('J s')?

Kevin

Re: Gnus losing information about what has been read

[Ralf Angeli]

* Kevin Greiner (2004-09-24) writes:

> Ralf Angeli <dev.null@iwi.uni-sb.de> writes:
>
>> * Kevin Greiner (2004-09-24) writes:
>>
>>> I'm trying an entirely different aproach now as it turned out that the
>>> nntp implementation required the server to be open for
>>> nntp-marks-file-name to be correct.
>>>
>>> It appears that the agent's synchronization function could actually
>>> try to write the flags back to itself. Then, having done so, delete
>>> the flags file so that all of the flags were lost.  I've added some
>>> additional checks.  Please give it a try.
>>
>> After a fresh CVS checkout I don't get the error related to
>> `nntp-marks-file-name' being nil anymore.  I noticed a message in the
>> echo area upon leaving a group in unplugged state with e.g. `q':
>>
>> Added to /home/angeli/News/agent/nntp/news.gmane.org/agent.lib/flags
>>
>> While there are no errors anymore, the marks are forgotten again.
>> Tested this by starting Emacs/Gnus in plugged state, downloading new
>> articles into the agent with `J s', switching to unplugged state with
>> `J j', reading the articles, shutting down Gnus in unplugged state
>> with `q y' and restarting Emacs and Gnus in plugged state.
>
> Have you customized gnus-agent-synchronize-flags?  If it is null,
> automatic synchronization will be completely turned off.

It is customized to t:

,----[ C-h v gnus-agent-synchronize-flags RET ]
| gnus-agent-synchronize-flags's value is t
`----

> From this description, the unplugged flags are being saved but never
> sync'ed.  In the last step, when you restart emacs and gnus in a
> plugged state, do you automatically perform a fetch session ('J s')?

No, I am always doing this manually.

-- 
Ralf

Re: Gnus losing information about what has been read

[Kevin Greiner]

Ralf Angeli <dev.null@iwi.uni-sb.de> writes:

> * Kevin Greiner (2004-09-24) writes:
>
>> Ralf Angeli <dev.null@iwi.uni-sb.de> writes:
>>
>>> * Kevin Greiner (2004-09-24) writes:
>>>
>>>> I'm trying an entirely different aproach now as it turned out that the
>>>> nntp implementation required the server to be open for
>>>> nntp-marks-file-name to be correct.
>>>>
>>>> It appears that the agent's synchronization function could actually
>>>> try to write the flags back to itself. Then, having done so, delete
>>>> the flags file so that all of the flags were lost.  I've added some
>>>> additional checks.  Please give it a try.
>>>
>>> After a fresh CVS checkout I don't get the error related to
>>> `nntp-marks-file-name' being nil anymore.  I noticed a message in the
>>> echo area upon leaving a group in unplugged state with e.g. `q':
>>>
>>> Added to /home/angeli/News/agent/nntp/news.gmane.org/agent.lib/flags
>>>
>>> While there are no errors anymore, the marks are forgotten again.
>>> Tested this by starting Emacs/Gnus in plugged state, downloading new
>>> articles into the agent with `J s', switching to unplugged state with
>>> `J j', reading the articles, shutting down Gnus in unplugged state
>>> with `q y' and restarting Emacs and Gnus in plugged state.
>>
>> Have you customized gnus-agent-synchronize-flags?  If it is null,
>> automatic synchronization will be completely turned off.
>
> It is customized to t:
>
> ,----[ C-h v gnus-agent-synchronize-flags RET ]
> | gnus-agent-synchronize-flags's value is t
> `----
>
>> From this description, the unplugged flags are being saved but never
>> sync'ed.  In the last step, when you restart emacs and gnus in a
>> plugged state, do you automatically perform a fetch session ('J s')?
>
> No, I am always doing this manually.

Are you willing/able to do a little lisp debugging for me?  If so, please do the following:
1) Run gnus as you've described up to the point where you've seen the 'Added to ... agent.lib/flags' message.
2) Start a new emacs process.
3) Do M-x load-library<ret>gnus-agent.el<ret>
4) Do M-x debug-on-entry<ret>gnus-agent-possibly-synchronize-flags<ret>
5) Do M-x gnus

The questions that I need you to answer are:

1) Is gnus-agent-possibly-synchronize-flags being called?  That is, do
   you ever drop into the debugger?

2) As you step through the execution.  You should see where gnus
   checks for the existence of the agent.lib/flags file.  There's one
   file for each server.  Does gnus check specifically for the
   news.gmane.org server's file?

3) If the file is found, gnus will attempt to open the server.  Does
   that open succeed?

4) Finally, a (eval (read (current-buffer))) expression is performed
   several times.  Does it seem to return normally or does it signal
   an error?

Kevin

Re: Gnus losing information about what has been read

[Kevin Greiner]

Kevin Greiner <kevin.greiner@vignette.com> writes:

> Ralf Angeli <dev.null@iwi.uni-sb.de> writes:
>
>> * Kevin Greiner (2004-09-24) writes:
>>
>>> Ralf Angeli <dev.null@iwi.uni-sb.de> writes:
>>>
>>>> * Kevin Greiner (2004-09-24) writes:
>>>>
>>>>> I'm trying an entirely different aproach now as it turned out that the
>>>>> nntp implementation required the server to be open for
>>>>> nntp-marks-file-name to be correct.
>>>>>
>>>>> It appears that the agent's synchronization function could actually
>>>>> try to write the flags back to itself. Then, having done so, delete
>>>>> the flags file so that all of the flags were lost.  I've added some
>>>>> additional checks.  Please give it a try.
>>>>
>>>> After a fresh CVS checkout I don't get the error related to
>>>> `nntp-marks-file-name' being nil anymore.  I noticed a message in the
>>>> echo area upon leaving a group in unplugged state with e.g. `q':
>>>>
>>>> Added to /home/angeli/News/agent/nntp/news.gmane.org/agent.lib/flags
>>>>
>>>> While there are no errors anymore, the marks are forgotten again.
>>>> Tested this by starting Emacs/Gnus in plugged state, downloading new
>>>> articles into the agent with `J s', switching to unplugged state with
>>>> `J j', reading the articles, shutting down Gnus in unplugged state
>>>> with `q y' and restarting Emacs and Gnus in plugged state.
>>>
>>> Have you customized gnus-agent-synchronize-flags?  If it is null,
>>> automatic synchronization will be completely turned off.
>>
>> It is customized to t:
>>
>> ,----[ C-h v gnus-agent-synchronize-flags RET ]
>> | gnus-agent-synchronize-flags's value is t
>> `----
>>
>>> From this description, the unplugged flags are being saved but never
>>> sync'ed.  In the last step, when you restart emacs and gnus in a
>>> plugged state, do you automatically perform a fetch session ('J s')?
>>
>> No, I am always doing this manually.
>
> Are you willing/able to do a little lisp debugging for me?  If so, please do the following:
> 1) Run gnus as you've described up to the point where you've seen the 'Added to ... agent.lib/flags' message.
> 2) Start a new emacs process.
> 3) Do M-x load-library<ret>gnus-agent.el<ret>
> 4) Do M-x debug-on-entry<ret>gnus-agent-possibly-synchronize-flags<ret>
> 5) Do M-x gnus
>
> The questions that I need you to answer are:
>
> 1) Is gnus-agent-possibly-synchronize-flags being called?  That is, do
>    you ever drop into the debugger?
>
> 2) As you step through the execution.  You should see where gnus
>    checks for the existence of the agent.lib/flags file.  There's one
>    file for each server.  Does gnus check specifically for the
>    news.gmane.org server's file?
>
> 3) If the file is found, gnus will attempt to open the server.  Does
>    that open succeed?
>
> 4) Finally, a (eval (read (current-buffer))) expression is performed
>    several times.  Does it seem to return normally or does it signal
>    an error?

Excellent news.  I've finally reproduced the problem.  It's very
subtle and I've no idea what specifically is happening so far.  As
best I can tell, I have to generate marks in several groups before the
problem occurs.  The agent part of the process seems to work fine yet
the group/summary buffers don't reflect the changes that are taking
place.

Kevin

Re: Gnus losing information about what has been read

[Ralf Angeli]

* Kevin Greiner (2004-09-24) writes:

> Are you willing/able to do a little lisp debugging for me?

Sure. (c:

> If so,
> please do the following:
> 1) Run gnus as you've described up to the point where you've seen
> the 'Added to ... agent.lib/flags' message.
> 2) Start a new emacs process.

I suppose that involves closing Gnus and Emacs and starting both
again.

> 3) Do M-x load-library<ret>gnus-agent.el<ret>
> 4) Do M-x debug-on-entry<ret>gnus-agent-possibly-synchronize-flags<ret>
> 5) Do M-x gnus
>
> The questions that I need you to answer are:

Below you can find the contents of the debugging window at the various
stages.  If I got them wrong please tell me and I'll try to provide
the right ones.  Note that the backtraces for questions 1) and 2) are
from a different session than the ones for questions 3) and 4).  As
the problem didn't change, I hope it is not significant.  I just had
to try several times until I got it right.

> 1) Is gnus-agent-possibly-synchronize-flags being called?  That is, do
>    you ever drop into the debugger?

Yes.

Debugger entered--entering a function:
* gnus-agent-possibly-synchronize-flags()
  (cond ((eq set-to gnus-plugged) nil) (set-to (setq gnus-plugged set-to) (gnus-run-hooks ...) (setcar ... ...) (gnus-agent-go-online gnus-agent-go-online) (gnus-agent-possibly-synchronize-flags)) (t (gnus-agent-close-connections) (setq gnus-plugged set-to) (gnus-run-hooks ...) (setcar ... ...)))
  gnus-agent-toggle-plugged(t)
  (let ((init-plugged gnus-plugged) (gnus-agent-go-online nil)) (setq gnus-plugged :unknown) (gnus-agent-toggle-plugged init-plugged))
  (progn (let (... ...) (setq gnus-plugged :unknown) (gnus-agent-toggle-plugged init-plugged)))
  (if (eq major-mode (quote gnus-group-mode)) (progn (let ... ... ...)))
  (when (eq major-mode (quote gnus-group-mode)) (let (... ...) (setq gnus-plugged :unknown) (gnus-agent-toggle-plugged init-plugged)))
  (let* ((buffer ...) (mode ...)) (set (make-local-variable ...) t) (set mode nil) (set (make-local-variable mode) t) (when (gnus-visual-p ... ...) (funcall ...)) (unless (assq ... minor-mode-alist) (push gnus-agent-mode-status minor-mode-alist)) (unless (assq mode minor-mode-map-alist) (push ... minor-mode-map-alist)) (when (eq major-mode ...) (let ... ... ...)) (gnus-run-hooks (quote gnus-agent-mode-hook) (intern ...)))
  gnus-agent-mode()
  run-hooks(gnus-group-mode-hook)
  apply(run-hooks gnus-group-mode-hook)
  gnus-run-hooks(gnus-group-mode-hook)
  gnus-group-mode()
  gnus-group-setup-buffer()
  gnus-group-list-groups(nil)
[byte-code stripped]
  gnus-1(nil nil nil)
  gnus(nil)
  call-interactively(gnus)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)

> 2) As you step through the execution.  You should see where gnus
>    checks for the existence of the agent.lib/flags file.  There's one
>    file for each server.  Does gnus check specifically for the
>    news.gmane.org server's file?

I tested with news.individual.net:

Debugger entered--returning value: "/home/angeli/News/agent/nntp/news.individual.net/agent.lib/flags"
  expand-file-name("flags" "/home/angeli/News/agent/nntp/news.individual.net/agent.lib/")
* gnus-agent-lib-file("flags")
* (file-exists-p (gnus-agent-lib-file "flags"))
* (if (file-exists-p (gnus-agent-lib-file "flags")) (progn (gnus-agent-possibly-synchronize-flags-server gnus-command-method)))
* (when (file-exists-p (gnus-agent-lib-file "flags")) (gnus-agent-possibly-synchronize-flags-server gnus-command-method))
* (while --dolist-temp--21402 (setq gnus-command-method (car --dolist-temp--21402)) (when (file-exists-p ...) (gnus-agent-possibly-synchronize-flags-server gnus-command-method)) (setq --dolist-temp--21402 (cdr --dolist-temp--21402)))
* (let ((--dolist-temp--21402 ...) gnus-command-method) (while --dolist-temp--21402 (setq gnus-command-method ...) (when ... ...) (setq --dolist-temp--21402 ...)) nil)
* (catch (quote --cl-block-nil--) (let (... gnus-command-method) (while --dolist-temp--21402 ... ... ...) nil))
* (cl-block-wrapper (catch (quote --cl-block-nil--) (let ... ... nil)))
* (block nil (let (... gnus-command-method) (while --dolist-temp--21402 ... ... ...) nil))
* (dolist (gnus-command-method (gnus-agent-covered-methods)) (when (file-exists-p ...) (gnus-agent-possibly-synchronize-flags-server gnus-command-method)))
* (save-excursion (dolist (gnus-command-method ...) (when ... ...)))
* gnus-agent-possibly-synchronize-flags()

> 3) If the file is found, gnus will attempt to open the server.  Does
>    that open succeed?

Debugger entered--returning value: open
  process-status(#<process nntpd>)
* nntp-open-server("news.individual.net" nil)
[byte-code stripped]
* gnus-open-server((nntp "news.individual.net"))
[byte-code stripped]
* gnus-check-server((nntp "news.individual.net"))
* (null (gnus-check-server gnus-command-method))
* (cond ((null gnus-plugged) (gnus-message 1 "You must be plugged to synchronize flags with server %s" ...)) ((null ...) (gnus-message 1 "Couldn't open server %s" ...)) (t (while ... ...) (delete-file ...)))
* (progn (set-buffer (get-buffer-create " *Gnus Agent flag synchronize*")) (erase-buffer) (nnheader-insert-file-contents (gnus-agent-lib-file "flags")) (cond (... ...) (... ...) (t ... ...)) (kill-buffer nil))
* (if (file-exists-p (gnus-agent-lib-file "flags")) (progn (set-buffer ...) (erase-buffer) (nnheader-insert-file-contents ...) (cond ... ... ...) (kill-buffer nil)))
* (when (file-exists-p (gnus-agent-lib-file "flags")) (set-buffer (get-buffer-create " *Gnus Agent flag synchronize*")) (erase-buffer) (nnheader-insert-file-contents (gnus-agent-lib-file "flags")) (cond (... ...) (... ...) (t ... ...)) (kill-buffer nil))
* (let ((gnus-command-method method) (gnus-agent nil)) (when (file-exists-p ...) (set-buffer ...) (erase-buffer) (nnheader-insert-file-contents ...) (cond ... ... ...) (kill-buffer nil)))
* gnus-agent-synchronize-flags-server((nntp "news.individual.net"))
* (progn (gnus-agent-synchronize-flags-server method))
* (if (or (and gnus-agent-synchronize-flags ...) (and ... ...)) (progn (gnus-agent-synchronize-flags-server method)))
* (when (or (and gnus-agent-synchronize-flags ...) (and ... ...)) (gnus-agent-synchronize-flags-server method))
* gnus-agent-possibly-synchronize-flags-server((nntp "news.individual.net"))
* (progn (gnus-agent-possibly-synchronize-flags-server gnus-command-method))
* (if (file-exists-p (gnus-agent-lib-file "flags")) (progn (gnus-agent-possibly-synchronize-flags-server gnus-command-method)))
* (when (file-exists-p (gnus-agent-lib-file "flags")) (gnus-agent-possibly-synchronize-flags-server gnus-command-method))
* (while --dolist-temp--20402 (setq gnus-command-method (car --dolist-temp--20402)) (when (file-exists-p ...) (gnus-agent-possibly-synchronize-flags-server gnus-command-method)) (setq --dolist-temp--20402 (cdr --dolist-temp--20402)))
* (let ((--dolist-temp--20402 ...) gnus-command-method) (while --dolist-temp--20402 (setq gnus-command-method ...) (when ... ...) (setq --dolist-temp--20402 ...)) nil)
* (catch (quote --cl-block-nil--) (let (... gnus-command-method) (while --dolist-temp--20402 ... ... ...) nil))
* (cl-block-wrapper (catch (quote --cl-block-nil--) (let ... ... nil)))
* (block nil (let (... gnus-command-method) (while --dolist-temp--20402 ... ... ...) nil))
* (dolist (gnus-command-method (gnus-agent-covered-methods)) (when (file-exists-p ...) (gnus-agent-possibly-synchronize-flags-server gnus-command-method)))
* (save-excursion (dolist (gnus-command-method ...) (when ... ...)))
* gnus-agent-possibly-synchronize-flags()

> 4) Finally, a (eval (read (current-buffer))) expression is performed
>    several times.  Does it seem to return normally or does it signal
>    an error?

Nope.  Here are some partial backtraces at various stages of
execution:

Debugger entered--returning value: (nntp-request-set-mark "comp.text.tex" (quote ((((311807 . 311810)) add (read)))) "news.individual.net")
  read(#<buffer  *Gnus Agent flag synchronize*>)
* (eval (read (current-buffer)))
* (null (eval (read ...)))
* (if (null (eval ...)) (gnus-delete-line) (write-file (gnus-agent-lib-file "flags")) (error "Couldn't set flags from file %s" (gnus-agent-lib-file "flags")))
* (while (not (eobp)) (if (null ...) (gnus-delete-line) (write-file ...) (error "Couldn't set flags from file %s" ...)))

...later...

Debugger entered--beginning evaluation of function call form:
* (nntp-request-set-mark "comp.text.tex" (quote (...)) "news.individual.net")
* eval((nntp-request-set-mark "comp.text.tex" (quote (...)) "news.individual.net"))
* (null (eval (read ...)))
* (if (null (eval ...)) (gnus-delete-line) (write-file (gnus-agent-lib-file "flags")) (error "Couldn't set flags from file %s" (gnus-agent-lib-file "flags")))
* (while (not (eobp)) (if (null ...) (gnus-delete-line) (write-file ...) (error "Couldn't set flags from file %s" ...)))

...even later...

Debugger entered--returning value: t
  null(nil)
* (if (null (eval ...)) (gnus-delete-line) (write-file (gnus-agent-lib-file "flags")) (error "Couldn't set flags from file %s" (gnus-agent-lib-file "flags")))
* (while (not (eobp)) (if (null ...) (gnus-delete-line) (write-file ...) (error "Couldn't set flags from file %s" ...)))

-- 
Ralf

Re: Gnus losing information about what has been read

[Jan Rychter]

>>>>> "Kevin" == Kevin Greiner <kevin.greiner@vignette.com>:
[...]
 Kevin> My patch was defective.  I had tested physical unplugging rather
 Kevin> than gnus "unplugged".  I've updated gnus-int.el again.

That seems to have fixed the problem for me. I'm still amazed this went
unnoticed with so many people...

thanks!
--J.

Re: Gnus losing information about what has been read

[Kevin Greiner]

Jan Rychter <jan@rychter.com> writes:

>>>>>> "Kevin" == Kevin Greiner <kevin.greiner@vignette.com>:
> [...]
>  Kevin> My patch was defective.  I had tested physical unplugging rather
>  Kevin> than gnus "unplugged".  I've updated gnus-int.el again.
>
> That seems to have fixed the problem for me. I'm still amazed this went
> unnoticed with so many people...

Sorry, but I've had to withdraw the patch.  Check out the latest to
try an alternative solution.

Kevin

Re: Gnus losing information about what has been read

[Jan Rychter]

>>>>> "Kevin" == Kevin Greiner <kevin.greiner@vignette.com> writes:
 Kevin> Jan Rychter <jan@rychter.com> writes:
 > "Kevin" == Kevin Greiner <kevin.greiner@vignette.com>:
 >> [...]
 Kevin> My patch was defective.  I had tested physical unplugging rather
 Kevin> than gnus "unplugged".  I've updated gnus-int.el again.
 >>
 >> That seems to have fixed the problem for me. I'm still amazed this
 >> went unnoticed with so many people...

 Kevin> Sorry, but I've had to withdraw the patch.  Check out the latest
 Kevin> to try an alternative solution.

Ahem, I've been bitten by the same problem once again. It hurt. So this
time I actually took some time to look into it. Here are the results:

-- I had gnus-agent-synchronize-flags set to nil for some reason. Why is
   that the default? :-O

-- setting it to 'ask and replying 'y' to the question about flag
   synchronization fixed the problem for me,

-- so I've now set it to t. I feel smarter.

-- perusing the Fine Manual as to what this flag actually does led me to
   the section about IMAP. I've never used IMAP and I do not intend
   to. I mostly use NNTP.

-- nowhere in the Fine Manual does it say that if I don't read about
   IMAP and gnus-agent-synchronize-flags, the information about NNTP
   articles that I've read offline will be forgotten and lost.

I submit that Gnus defaults to the wrong thing here, because I seriously
doubt whether forgetting about articles that one has read offline is
something anyone would want by default.

--J.

Re: Gnus losing information about what has been read

[Kevin Greiner]

Jan Rychter <jan@rychter.com> writes:

>>>>>> "Kevin" == Kevin Greiner <kevin.greiner@vignette.com> writes:
>  Kevin> Jan Rychter <jan@rychter.com> writes:
>  > "Kevin" == Kevin Greiner <kevin.greiner@vignette.com>:
>  >> [...]
>  Kevin> My patch was defective.  I had tested physical unplugging rather
>  Kevin> than gnus "unplugged".  I've updated gnus-int.el again.
>  >>
>  >> That seems to have fixed the problem for me. I'm still amazed this
>  >> went unnoticed with so many people...
>
>  Kevin> Sorry, but I've had to withdraw the patch.  Check out the latest
>  Kevin> to try an alternative solution.
>
> Ahem, I've been bitten by the same problem once again. It hurt. So this
> time I actually took some time to look into it. Here are the results:
>
> -- I had gnus-agent-synchronize-flags set to nil for some reason. Why is
>    that the default? :-O

It was originally nil then changed to ask.  Unfortunitely, that
introduced a host of problems as the sync code simply didn't work as
intended.  While I was still trying to track down bugs, Lars reviewed
the situation and noticed that we were defaulting to an interactive
prompt.  That's actually against gnus conventions so he had to choose
between enabling, or disabling, buggy code.

> -- setting it to 'ask and replying 'y' to the question about flag
>    synchronization fixed the problem for me,
>
> -- so I've now set it to t. I feel smarter.
>
> -- perusing the Fine Manual as to what this flag actually does led me to
>    the section about IMAP. I've never used IMAP and I do not intend
>    to. I mostly use NNTP.
>
> -- nowhere in the Fine Manual does it say that if I don't read about
>    IMAP and gnus-agent-synchronize-flags, the information about NNTP
>    articles that I've read offline will be forgotten and lost.
>
> I submit that Gnus defaults to the wrong thing here, because I seriously
> doubt whether forgetting about articles that one has read offline is
> something anyone would want by default.

I agree.  I'll change it to true (t) once I gain a little more
confidence in the current implementation.

Kevin

Re: Gnus losing information about what has been read

[Jan Rychter]

[...]
 >> -- I had gnus-agent-synchronize-flags set to nil for some
 >>    reason. Why is that the default? :-O

 Kevin> It was originally nil then changed to ask.  Unfortunitely, that
 Kevin> introduced a host of problems as the sync code simply didn't
 Kevin> work as intended.  While I was still trying to track down bugs,
 Kevin> Lars reviewed the situation and noticed that we were defaulting
 Kevin> to an interactive prompt.  That's actually against gnus
 Kevin> conventions so he had to choose between enabling, or disabling,
 Kevin> buggy code.

 >> -- setting it to 'ask and replying 'y' to the question about flag
 >> synchronization fixed the problem for me,
 >>
 >> -- so I've now set it to t. I feel smarter.
 >>
 >> -- perusing the Fine Manual as to what this flag actually does led
 >>    me to the section about IMAP. I've never used IMAP and I do not
 >>    intend to. I mostly use NNTP.
 >>
 >> -- nowhere in the Fine Manual does it say that if I don't read about
 >> IMAP and gnus-agent-synchronize-flags, the information about NNTP
 >> articles that I've read offline will be forgotten and lost.
 >>
 >> I submit that Gnus defaults to the wrong thing here, because I
 >> seriously doubt whether forgetting about articles that one has read
 >> offline is something anyone would want by default.

 Kevin> I agree.  I'll change it to true (t) once I gain a little more
 Kevin> confidence in the current implementation.

Thanks for the clarifications.

Perhaps the handling of NNTP and IMAP should be separated here? I can
imagine why it is useful to either synchronize marks or not when using
an IMAP server, but I can't think of a case where I would want to forget
about NNTP articles that I've read offline.

These really are different issues.

--J.

Re: Gnus losing information about what has been read

[Jan Rychter]

Kevin Greiner:
> Ralf Angeli <dev.null@iwi.uni-sb.de> writes:
> > * Jan Rychter (2004-09-21) writes:
> >
> >> [Quoting my post from about 2 weeks ago...]
> >>>>>>> "Jan" == Jan Rychter <jan@rychter.com> writes:
> >>  Jan> Ok. My Gnus has just forgotten which articles I have read in some
> >>  Jan> groups. Again. I have long had the impression that it does that
> >>  Jan> behind my back sometimes, but I was never sure enough. This time
> >>  Jan> I'm quite sure, because it has forgotten about roughly 1k
> >>  Jan> articles.
> >>
> >>  Jan> This seems to happen for me in agentized groups that I read while
> >>  Jan> unplugged -- after I go online again, the articles are visible as
> >>  Jan> "unread", again.
> >>
> >>  Jan> I'm using No Gnus 0.3, updated from CVS on Aug 5, under XEmacs --
> >>  Jan> but I'm quite sure the problem has been there for quite some time.
> >>
> >>  Jan> Any ideas?
> >>
> >> I am rather alarmed by the number of responses to this report -- namely:
> >> zero.
> >>
> >> Am I the only one who sees that?
> >
> > I don't know exactly if it is the same problem, but for me Gnus
> > forgets marks with the following usage pattern:
> >
> > When being online, start Gnus in "Plugged" state (`emacs -f gnus').
> > Download new (nntp) articles with `J s' into the agent.  Go into
> > "Unplugged" state with `J j'.  Read the new articles or mark them as
> > read, e.g. with `c y'.  Close Gnus with `q y' and close Emacs.  Start
> > Emacs/Gnus again in "Plugged" state.  The read articles will be marked
> > unread again.  (If it doesn't "work" the first time, maybe try the
> > pattern once again.)  One can distinguish read articles which are not
> > marked as read from really new articles.  The latter have an unseen
> > mark (`.') in the summary buffer.
> >
> > Those problems started with the introduction of marks for nntp.
> 
> These problems occur because you are not sync'ing the marks that were
> cached in the agent (while unplugged) when you next plug in.  What you
> have to do is press 'J Y' in the group buffer BEFORE opening a summary
> buffer.
> 
> If you don't want to do the 'J Y', update to "No Gnus 0.3, Sept 21".
> I just checked in the patch to always bypass the agent when writing
> nntp marks.

I have just:

  -- updated from CVS, recompiled, restarted, etc.
  -- read 2 articles in gmane.emacs.gnus.general while unplugged
  -- quit Gnus
  -- restarted XEmacs
  -- started Gnus (plugged)
  -- answered 'y' to the question about whether to synchronize marks on
     news.gmane.org

... and the articles are again not marked read.

What's even stranger (for me) is that these 2 articles have disappeared
from the cache. I can't read them while unplugged.

This is a total showstopper for me.

--J.

Re: Gnus losing information about what has been read

[Xavier Maillard]

On 21 sep 2004, Jan Rychter wrote:

> [Quoting my post from about 2 weeks ago...]
> > > > > > "Jan" == Jan Rychter <jan@rychter.com> writes:
> Jan> Ok. My Gnus has just forgotten which articles I have read
> Jan> in some groups. Again. I have long had the impression that
> Jan> it does that behind my back sometimes, but I was never
> Jan> sure enough. This time I'm quite sure, because it has
> Jan> forgotten about roughly 1k articles.
> 
> Jan> This seems to happen for me in agentized groups that I
> Jan> read while unplugged -- after I go online again, the
> Jan> articles are visible as "unread", again.
> 
> Jan> I'm using No Gnus 0.3, updated from CVS on Aug 5, under
> Jan> XEmacs -- but I'm quite sure the problem has been there
> Jan> for quite some time.
> 
> Jan> Any ideas?
> 
> I am rather alarmed by the number of responses to this report
> -- namely: zero.
> 
> Am I the only one who sees that?

In fact you are not alone. It took me some times to see this
problem here.

I can confirm what you and other people have seen. I suspect
a problem with the server sync but not only since I sync with my
server only on the evening and all along the day, my marks are
simply forgotten between Gnus sessions...

Maybe it is deeper than I think ...
-- 
 In Gruuik we trust