nmh-workers
[Top] [All Lists]

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

2013-03-27 10:03:48
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
got:

  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.

David

_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>