In regard to: Re: mailutil appenddelete silently loses mail?, Mark Crispin...:
If by "the other 20 megabytes" you are referring to the difference between 53775404 and 31356329,
Yes.
that difference is probably in expunged messages which never got garbage collected because the expunge was always from a shared-access session.
The way to test that is to expunge INBOX.head without multiple access. I bet that you'll find that it shrinks by that about that amount.
You're exactly correct. I wasn't expecting that there would be a case where messages wouldn't show up in the index (even marked for deletion) but would be hanging around in the folder. Pressing x within pine even indicated "no messages expunged", but the size shrunk to match the other folder exactly. I understand now though -- the messages were already expunged, they just weren't excised from the folder yet.
The last 8 bytes in the internal header are the message UID. Newly delivered messages get a UID of 0, which causes a UID to be assigned the next time the mailbox is opened (as opposed to append). Otherwise, append would have to go to a lot more work.
Ok.
What's the best source for information on the MBX internal header? I think it's time I learn the signficance of the various bytes in the internal header after the ;.
" 3-Aug-2004" and "03-Aug-2004" are exactly equivalent. One happens when the date is provided, the other happens when the date is defaulted. It's not worth fixing.
Thanks for the info.
Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164
