That happens on both 32- and 64-bit Linux. So as of right
now, with your new locking code, I don't need to worry about
losing any sequence information, right?
I believe so (fun fact; the old locking code released the lock on the
file before it called fclose(). Whoops). But when you say "64-bit"
Linux, what does that mean, exactly? Do they have different compiler
memory models? That's the real issue here. On your 32-bit system, is
it ILP32 or LP64?
32-bit Linux is ILP32, 64-bit Linux is LP64.
Same for 32- and 64-bit Solaris.
I seqset_t is changed to an 8-byte long on 64-bit Linux,
that would no longer be true, right?
That is true.
Then let's not.
Well, unless your 32-bit linux is an LP64 system;
Then it's 64-bit Linux :-)
It looks like it'd be easy to propagate the error back to
folder_read(). Every caller of that checks its return
value. I don't understand how "more correct" can be "wrong".
Think about the consequences here. If folder_read() returns an error,
that means nmh stops working; hence the reason fixing sequence file
corruption was dealt with in the first place. If nmh stops working,
that means that programs like rcvstore and inc stop working, which means
you stop getting mail. Clearly this was why previous iterations of the
code erred on the side of silently eating errors.
Personally, I'd rather have complain-and-stop than silently
eat an error. I can then fix it and try inc again. rcvstore
takes more care, but any program that can fail should be
expected to. And all nmh programs can fail.
Though I understand the desire to not stop working, I think
the current behavior is the worst choice. There should at least
be warning (admonish(), even though Norm doesn't like them) messages.
And then there's the 60 or so adios() calls in sbr/. Really, all of
this should be revisited but I expect no one here has the time now.
In the meantime, adding another warning message to sbr seems like a
big net positive to me.
And let's think about the situation where that would occur. You
can't use the standard tools to add those sequences, unless you've
got the old-code/new-code problem. You'd have to work at it.
That's my point above. I don't want to give that up.
David
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers