Bruce Guenter <bruceg(_at_)em(_dot_)ca> writes:
On Tue, Nov 23, 1999 at 02:30:57PM -0600, Philip Guenther wrote:
The format is
an underbar
This seems frivolous. If you're interested in shorter filenames, why
add arbitrary characters to it?
Ease of identification. Decrease the chance of conflict with other
programs. Tradition.
the pid, base64 encoded left to right
one of the set .,+:%@
What determines which one of these are used? IMHO, unless there is a
reason to add more bits of data here, this should be a period.
To allow procmail to deliver more than once a second.
the time, base64 encoded left to right
Just out of curiosity, was there a reason for putting pid before time in
the file name format (qmail does time before pid).
The pid doesn't change during the process of creating a unique filename,
the time may, depending on whether retries are needed. Putting the pid
first avoid having to convert it to ascii again.
...
According to the
"HOW A MESSAGE IS READ" section, programs which read messages in maildir
folders treat the actual filename as an opaque blob, so the above method
of picking a unique filename should work fine.
True, except that anything following a ":" is treated as "info", to be
interpreted by the reader as flags. So, in the above format
description, some file names generated by procmail will cause readers to
mishandle the flags, since procmail generates some names with ':' in
them. Readers use these flags to mark a message as read/old/replied/etc
rather than modifying the contents of the message.
That dang purloined letter strikes again. You are correct, ':' should
not be used in the filename when delivering to maildir mailboxes.
I've corrected the source to not use it.
I guess this means there'll be a version 3.14.1 sometime relatively soon.
<sigh>
Philip Guenther