The scan listing for 'inc' is being generated as it's reading the
spool file. So the ONLY way for you to get two scans is for you do
actually incorporate the mail twice. The spool is locked, yes ... but
I see from the code it's unlocked before it gets truncated
Is it? I didn't notice that in 1.6.
Oh, hm. You know ... I think I'm wrong there. I realize now that I
was looking at the code which gets triggered on error. Looking at things
more closely, I see that it gets truncated, then unlocked. Sigh, inc.c
is kind of a mess.
So, I'm puzzled. But maybe fetchmail is causing the spool file to be
rewritten? Unless I'm misreading inc.c (which has happened :-) ), you
shouldn't get a second scan listing unless you're reading the spool
file again.
Sounds plasible... I haven't delved deep enough, but wouldn't the creat
of [9704, 9712] have failed if the files already existed?
At least on my system, it says creat() is equivalent to O_CREAT |
O_TRUNC | O_WRONLY. Not O_EXCL.
Well, the locks are advisory only, so I don't think the kernel's locking
code cares what happens to the file, e.g. writing to it, or truncating
it.
I was more thinking about if you truncate a file with existing locks; does
it cause further locks to succeed? I can't really see how that would happen
unless the spool is rewritten.
(although I see that it uses creat() to truncate a file, rather than
ftruncate(); that seems weird to me?).
And it's a bug it closes creat's FD, freeing the lock.
Oh, yes, that happens! Good catch!
I'd like to point out that it has never been safe to run two inc's at
the same time, so it's not surprising that this caused problems.
Ouch! I've just skimmed inc(1) and see no sign of that restriction? I
think I'll make a ~/bin/inc that uses flock(1).
You should be able to change that at runtime. And in general, it's not
guaranteed to be safe to run any two nmh commands at the same time. Like,
running sortm at the same time as anything else would be bad. I think with
locking it's safer than it has been in the past, but clearly somethign
odd is going on here.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers