Re: flist -- "Killed" -- oom (*not* 1.8 related)

[Ken Hornstein]

>a folder with the highest message number of "N" will cause the array to be
>configured to support N messages, even if there are many fewer (perhaps
>even one) messages

No, that's not correct.  If you have a single message in a folder with a
count of 1000000, you only get one entry allocated.  The number of entries
allocated is based on the difference between the lowest and highest
message number.

>Scale the array based upon the number of directory entries in the folder.
>This will over commit due to subfolders being counted, scratch files, and
>deleted messages. It seems this would only over commit in interesting cases
>by 3x (baseline of 1 covers the messages, the 2nd set is scratch files and
>deleted messages, and 3 is subfolders). Short of malicious actions, you'd
>end up with, maybe 5x (message, extracted parts of the message, deleted
>message, folders that look like message numbers). If you want more
>compactness, you take pains to dump the stuff that isn't a message number
>(the aforementioned extracted parts and deleted messages).

It's not filesystem internals that is the issue, it's (n)mh internals.

Right now the msgstats array is indexed by taking the message number and
subtracting the value of the lowest message number.  Obviously there are
much better ways to deal with this, but all of the nmh code directly
accesses the msgstats array.  And of course time is not infinite so
someone who HAS time would have to roll up their sleeves to fix it.

(A general assumption is that there are few holes in nmh message
numbers and this is reflected in more locations than just this).

--Ken