Re: [mpop-users] [PATCH] Add an option to disable hard-links usage

[Martin Lambers <marlam@...1...>]

Hi Sebastien!

On Mon, 12. Jan 2009, 22:12:48 +0100, Sebastien Raveau wrote:
> I'm writing to say I am a happy user of mpop, but I've always felt
> bit bothered that I couldn't use it inside an EncFS (encrypted
> filesystem) with maximum-security settings...
> 
> The thing is, when the "filename to IV header chaining" feature
> is enabled in EncFS, the file data encoding depends on the
> filename, and therefore hard-links are not supported.
> 
> This patch doesn't change anything in the way mpop works
> by default. It just adds the --no-links option so that users on
> filesystems that do not support hard-links can switch to
> standard file renaming.

The problem is that maildir folders were designed for filesystems with
support for hard links. Without hard links, it is not possible to
properly support maildir folders. You will always have a race condition.

The link()/unlink() pair for bringing a mail from the tmp subdirectory
to the cur subdirectory cannot be simply replaced with a rename() call,
because that might overwrite an already existing file of the same name
(the Win32 code has a bug here). There are two possibilities:
a) First check with stat() that the file does not already exist, then 
call rename().
b) open() a file with O_CREAT | O_EXCL, ensuring that it did not exist
before, and then call rename().

a) has a race condition between stat() and rename().
b) has a period of time in which the file exists and is empty, but
maildir folders guarantee that reading programs need not care about
partially written mails in the cur subdirectory.

One could argue that a) is "good enough" and could be used if hard links
are not available in the filesystem. It would be nice to detect that
automatically to avoid adding the --no-links option, but POSIX defines
no errno value for this condition, FreeBSD uses EOPNOTSUPP, Linux uses
EPERM (which is also used for other error conditions), and who knows
what other systems might use.

So we could either document that maildir folders can only be used on
file systems with hard links and not change the code, or we could add a
--no-links option and add a warning in the man page that this will
result in a race condition and should only be used if the maildir folder
is never used by concurrent processes (which defeats the point of using
maildir folders). I'd vote for the first option.

Either way, the Win32 code should be fixed to use Win32 hard links.
Ideally, this would be done by gnulib modules that provide
link()/unlink() replacement functions around the Win32
CreateHardLink()/DeleteFile() functions, so that we can keep using the
POSIX API.

Regards,
Martin