nmh-workers
[Top][All Lists]
Advanced

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

Re: [Nmh-workers] Limit of 27 messages sequences per folder


From: David Levine
Subject: Re: [Nmh-workers] Limit of 27 messages sequences per folder
Date: Wed, 27 Mar 2013 12:30:44 -0400

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



reply via email to

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