Re: pop3d and imap4d's locking behaviour

[Alain Magloire]

> 
> It seems to me that in theory, you should always lock a file
> before reading it, otherwise you can read it while somebody
> else is writing it. You should only do so as long as you need
> to, of course.

You are getting in an area where flat mbox is a real disavantage/problem.
So when to lock? For an industrial strength program, you pretty much
have to lock at __all__ operations.  Or be smarter, maintaining a mtime
and throw an error when you are no longer consistent.  This can
be very cumbersome for programming, especially simple readonly
program like frm/messages/from etc ..

> 
> Is it really that important of an optimization to not dotlock
> a file?

For distributed systems (say NFS), many implementations
have very effective read caching, but a simple write takes hours(Ok, maybe
a few seconds) but still for lot of transactions you pay the price.
An other example, my mailbox contains 2000 msgs(yes I know..)
It would not be efficient to create/delete 2000 times the .lock file.

> That's why I thought about the MU_LOCKER_NO_LOCK, then
> if you truly don't care about the data (like messages), what the
> hell, you can disable locking.

can it be an option MU_LOCKER_NO_LOCK_ON_READ 8-) ?

Also note that elm uses a second approach: to copy the entire mbox
in /tmp/MBOX.user or something and work with this version.

Maybe we could provide the same:
mailbox_cache(mailbox_t *, char * url_src, char *url_dst);

mailbox_cache(&mbox, "/var/mail/alain", "/tmp/Mbox.alain"); 

mailbox_cache would take care of maintaining the sync.
It could be usefull for things like:
mailbox_cache(&mbox, "pop3://address@hidden", "/home/alain/mail/pop3"); 

This was to be for mailutils2, because there is currently no sync interface
to deal with remote mailboxes like POP3 or IMAP4.