[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    RE: maildir handling (was Re: Need for a general purpose databas
From:       Rik Hemsley <rik () rikkus ! demon ! co ! uk>
Date:       1999-07-19 9:45:36
[Download RAW message or body]


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

[prev in list] [next in list] [prev in thread] [next in thread]