Re: Something fundamental - how nov works

[Harry Putnam <reader@newsguy.com>]

Simon Josefsson <jas@extundo.com> writes:

> Did you check if the active file was updated correctly?

I hadn't posted back about it yet, but I did discover that was the
source of at least some troubles.  Apparently when
nnml-generate-nov-databases-1 is run the ~/Mail/active file is not
updated.  Is that a good thing?  Is that even a good place to keep
information on what is read?

> >
> > No matter what I do 6 isn't visible to gnus.  It is in the nov file
> > though.  So apparently some other condition is not being met here.
> 
> I assume you are entering the group with C-u RET?

Yes and also with Karls suggestion of M-<RET>
 
> Do you have any `display' group properties on the group?  Perhaps post
> the output from `G E' on the group, and `G p' on the topics in which
> the group is located.

No topic in use.

Nothing special there, no.  This output shows only 3 messages but this
is accurate at this point>
`G E'
("nnml:todo" 3 nil nil "nnml:")

> Perhaps you are better off using nnmh, nnmbox, nnmaildir or similar
> instead of nnml if you want to write to the server outside of Gnus
> though.  Or write your script in elisp, using Gnus functions to enter
> articles into the group.

Question about this last suggestion:
Do you mean that nnml, nnmbox, nnmaildir in some way are less
sensititve to sneaky input.  (input from outside gnus) can you explain
that a bit? 

I found a way that makes use of your last point there.  Using gnus
functions, without having to know enough lisp to pull it off.

By writing the data in mbox format to a spool where gnus thinks it is
procmail output, slurps it and writes it to the nnml group.

That works pretty well.

A problem I considered there is the event where my script is writing
to the procmail like spool when gnus is slurping.  I guess that is
where locking of some kind comes up.

I investigated `man lockfile' and was disgusted to find that the
discussion and example there are so general as to be useless for a
practical guide.

It appears there is some way to lock the spool file but the syntax
given there doesn't work for me.

With these details:
homeboy script = `write_mbox.sh'

spool file  = ~/spool/todo.in

`todo.in' is the target file of the homeboy script and also seen by gnus
as a file to slurp when pulling in `mail-sources'

There is some chance that both activities could occur at once

So it seems one could introduce a call to `lockfile' in write_mbox.sh
that would lock the target file  during the time the script writes to it.

But various attempts at calling lockfile in the script like this:
cat write_mbox.sh

[...]
  lockfile ~/spool/todo.in.lock
   ..[ script action part]...
  rm -f  ~/spool/todo.in.lock
[...]

Looks like what the man page suggests but by commenting out the rm -f
so the lock stays on for testing, I find I can access that file at
will from the command line, write to it with echo or whatever, so
apparently it isn't being locked at all.

If I say `lockfile ~/spool/todo.in'
lockfile just hangs ad infinitum.
But the file is still accessabel to other activitiy.

99.9 percent of the time this wouldn't come up, but there is some
chance it would.

I thought about trying to employ movemail somehow but it appears to be
usefull only for rmail type files (babyl?)

A couple of people mentioned nnmaildir as a better approach, so I'm
investigating that now.

But it seems that in any case the potential to access a file by two
activities at once would exist.  So I guess I need to figure out how
to lock it for a moment while my script writes to it.