On Wed, Nov 24, 1999 at 09:53:40PM -0600, Philip Guenther wrote:
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
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.
As in, to allow procmail to deliver from the same pid to the same folder
more than once a second. Would it not be more advisable to add another
base64 digit somewhere that would provide you 64 possibilities instead
of just 6?
FWIW, my solution has always been to increment the seconds number on
subsequent deliveries. The only way this can introduce problems is if
you deliver N times to the same folder from the same PID, and within N
seconds wrap the PID and deliver to the same folder. Even then, the
solution is to wait a couple seconds and re-write.
Hmmm... the maildir man page doesn't indicate what to do if the link
into "new" fails. I would think that since the file in "tmp" already
exists, re-writing that file is a waste, and the MDA should just wait a
couple of seconds, create a new filename (different seconds number) and
retry the link.
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.
Unfortunately it breaks ordering the delivery times with user tools like
"sort". I would not think that reconversion from a pid to ascii takes
enough time to make this a significant consideration. Oh well.
Bruce Guenter <bruceg(_at_)em(_dot_)ca>