On 20-Jul-99 Stefan Taferner wrote: > On Sun, 18 Jul 1999, Rik Hemsley wrote: >> On 19-Jul-99 Stefan Taferner wrote: >> > On Thu, 15 Jul 1999, Rik Hemsley wrote: >> > [...] >> >> Here's a description of how to write to Maildir from man 5 maildir: >> >> >> >> The tmp directory is used to ensure reliable delivery, as >> >> discussed here. >> >> >> >> A program delivers a mail message in six steps. First, it >> >> chdir()s to the maildir directory. Second, it stat()s the >> >> name tmp/time.pid.host, where time is the number of sec- >> >> onds since the beginning of 1970 GMT, pid is the program's >> >> process ID, and host is the host name. >> > >> > I do not understand what this is for. >> > Can you please enlighten me? >> >> Which bit don't you understand ? > > Why the file is created. It seems to be a lock file, but it is only unique > to the one process at the current second. So it will only block multiple > accesses from the same app. > > Usually I would expect to lock the whole folder somehow, but this does > not seem to be done ... at least not from the explanation in the manpage. There are no locks. The tmp here isn't /tmp (in case you thought so ;) You stat the name you want to write to in tmp to check you're not overwriting anything. This shouldn't happen as the name should be unique. The only way you could end up trying to write a duplicate name is if a host with the same name, using the same pid, and with the same sequence number, tries to write. Even if that happens, you simply give up and refuse to deliver. The name you're stat()ing is that of the file you want to write the mail message to. If you successfully write this file, you link to new and you're delivered. When a client starts, it checks tmp for old mail and removes any older that a certain no. of days. It then renames all mail in new into cur. This marks them as seen by the client. To mark as read by the user, you mess with the flags on the end of the filename. If you want to see how it works in practice, read empath/lib/Maildir, method '_write(RMM::Message)'. It's commented with the full procedure at the top and all the way through. I'm keen on using the same principle in other situations where the requirements are similar, e.g. when storing addressbook records. There's no other way I know of (other than relying on a fs/database that does versioning) to ensure complete safety. Note that you don't lose any speed as you're free to use an index. Then you've got the locking problem again though :( My plan for getting around this for Empath is simply to call the index '.empathIndex', assume no process other than Empath will write to it, and use dotlocking. This should be absolutely safe iff no other process touches it. Cheers, Rik -- KDE - Colour outside the lines : http://www.kde.org [[without]] - software for KDE : http://without.netpedia.net