Christopher Lindsey <lindsey(_at_)ncsa(_dot_)uiuc(_dot_)edu> writes:
Looking at mailfold.c, it looks like it's a representation of the
inode number that the file is stored at. It essentially converts the
number into a string made of characters within the set [A-Za-z0-9-_].
This brings up an issue that I had wondered about though... What does procmail
do in this mode if the file already exists for a given inode? For example,
if a directory was restored from tape, the names would no longer correspond
with the right inode number.
In some quick tests it looks as though procmail replaces the original file
with a new one containing the same name. I'm not an MH user, so I don't know
what the ramifications are.
You are correct. For non-MH mail directories, the mail is rename()d
into place, so that it will result in the unlinking of the old file.
If you deliver to two different folders (by putting two directories on
the action line), procmail uses the link() system call to do the second
message, and link() can't replace existing files. Hmm, I suppose
procmail could be taught to always use link() with some sort of
fallback if the file already exists.
MH mail directories are safe as the name has nothing to do with the
inode number.
Philip Guenther