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 ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ mpop-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mpop-users
