[Top][All Lists]

[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 11:04:16 -0400

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

Right.  My concern is adding the potential for more breakage
than we already have.  I don't think there's anything we can
or should do about people who mix old and new MH/nmh
versions, manipulate a sequences file outside of nmh, or use
any other rope to hang themself.

Fortunately, moving to new nmh versions helps reduce problems
with sequences files.  I'd like to keep it that way.

Let me be concrete.  I use 32-bit and 64-bit Linux with my
MH folders shared via NFS.  The way things are right now, I
can't create more than 27 sequences (including cur) via
mark(1), pick(1), or rcvstore(1), right?  I just tried and

  mark: only 27 sequences allowed (no room for seq27)

  pick: only 27 sequences allowed (no room for foo)!

  rcvstore: only 27 sequences allowed (no room for unseen)!

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 seqset_t is changed to an 8-byte long on 64-bit Linux,
that would no longer be true, right?

If we're already broken on 64-bit Solaris or whatever, we
should fix it, add warnings, or document it, but that's a
different issue.  Just because we're broken there now doesn't
mean we should intentionally add breakage where we don't
currently have it.

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

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".
It's much better than losing information.  We should fix
that in any case, but I'll agree that we should avoid the
problem in the first place.  I think we can almost prevent
the problem, except for running out of memory.  But that's
unlikely these days.


reply via email to

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