Jan Vicherek asked,
| (I'm not subscribed, so please CC replies to me and mail me whether
| you know of any archives of this list)
The list is archived at the site where it runs: use SmartList's standard
archive commands (starting with "archive help" if you don't know them).
| quoting from the man page :
|
| If /var/spool/mail/$LOGNAME is a bogus mailbox (i.e. does not belong to the
| recipient, is unwritable, is a symbolic link or is a hard link), procmail
| will upon startup try to rename it into a file starting with `BOGUS.'
| Why can't I have [an extra] hardlink ?
Here's the problem as I understand it: you have an existing plain folder
with more than one hard link. Say it is both /path/one/to/name/a and
/path/two/to/name/b. Then you have two separate recipes that write to it
under its two different names, and they get triggered at the same time.
So one recipe tells procmail to lock /path/one/to/name/a.lock and the other
recipe tells procmail to lock /path/two/to/name/b.lock. Both procmail pro-
cesses think they have the lock and both write to the file, mixing text.
| Why can't I have a softlink ?
Same reason: one recipe tries to lock /name/of/symlink.lock while another
tries to lock /name/of/hardlink.lock, both think they have the lock, and
they mix text. Even kernel-locking strategies might get confused here,
because the symlink and the hard link have different inode numbers.
Note that you *can* save to a folder that has a symlink pointing to it, as
long as you do it under the name of its one and only hard link. You also can
save to a folder by a path that goes *through* a symlink to a directory to
get to the folder, as long as the folder itself is named by a hard link and
has no other hard links (or doesn't yet exist).
I think that a save-to-directory works even if the directory target is named
by a symlink.