nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Truncated Email.


From: Ken Hornstein
Subject: Re: [Nmh-workers] Truncated Email.
Date: Sun, 06 Mar 2016 13:31:28 -0500

>> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]