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

[Ken Hornstein]

>Would that bring us to where a 32-bit executable could lose
>information created by a 64-bit executable via a common sequences
>file?  If so, either we shouldn't do it, or should add code
>to protect against the loss.  It's wrong to allow silent loss.

I assume you mean "sizeof(seqset_t) == 32" (let's call that "SST32") and
"sizeof(seqset_t) == 64" (SST64).  We already have some SST64 systems today
(but based on warnings I remember seeing on some Solaris systems, it may
not work properly).  The concern here is if you use an SST32 executable
with a sequence file that has more than 27 sequences, right?

I kinda feel that "it might affect some people in edge cases" is
not good enough of a reason to not make this change.  The logical
conclusion from that position is that the sequence limit can never
be increased.  If the concern is old code, we're kinda stuck there;
the old code silently ate the extra sequences and has done so for
approximately forever.  Also, the sequence files have been vulnerable
to corruption and data loss for literally decades so it's not like it's
some super-reliable data store; if you're an old MH user, you couldn't
count on those things to stick around forever; if you used rcvstore,
you probably couldn't count on them to last a week.  I'm just trying
to provide some historical perspective here; the idea of "reliable"
sequence files is actually a new concept (and really, I only committed
the transactional locking code a week or two ago; before that you
could still have silent data loss).  Also, the solution to this
problem is simple: if you are in one the edge cases, simply don't make
more than 27 sequences (just like now).

Now, that's not to say we can't do BETTER going forward.  The "silently
eats extra sequences" code is in sbr/seq_read.c.  Basically, the return
value from seq_init() is being ignored; it returns -1 if there are too
many sequences.  So, if seq_init() returns -1, what do people suggest we do?
Emit a warning?  That would be from within a library function, which is
architecturally icky.  Error out like what is done now with a corrupt
sequence file?  Maybe more correct, but that seems wrong to me.  Continue
doing nothing?  It would be in line with historical practice but enough
people have voiced their objections to this, and it leaves me a bit
unsettled as well.

--Ken