bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [bug-mailutils] Lock with external program question


From: Alain Magloire
Subject: RE: [bug-mailutils] Lock with external program question
Date: Thu, 22 Sep 2005 12:51:57 -0400


> 
> > This seems to cover most cases, so the locker_t object did not allow to
> > overload its behaviour besides, providing the behaviour with the flags
> at
> > creation locker_create(..., flags);
> >
> > I'm curious, what scenario did we not cover, with all the flags define
> in
> > locker.h?
> >
> 
> The issue is that I want to use a combination of methods for locking
> (dotlock WITH kernel fcntl). This need comes from the fact that the
> various programs that access the mailboxes (imap server, pop server)
> lock with different ways, so we want the mda to lock with all possible
> ways when delivering to mailboxes.
>

An interesting point, I guess it would be nice to do multiple locking in
general.  It is probably not possible to now when the mailbox is on a
distributed file system, doing the kernel locking __and__ the dot-locking
could be a good thing.  Changing the code in locker.c to allow this may be
an option i.e. it is no longer exclusive. 
 
> >From what Sergey told me in a previous thread you have to use 2 locker
> objects and handle the one 'by hand' (see
> http://lists.gnu.org/archive/html/bug-mailutils/2005-07/msg00008.html)
> 
> I can do this in my mda where I handle delivery to the user's INBOX,
> but I cannot do it in the sieve fileinto action, unless I tamper with
> the fileinto action code (which is something I do not want).
> 
> Any suggestions are highly welcome.
> 

You could temper with the options of sieve asking for a specific/multiple
lock types when it opens the mailbox or save the file in a different folder:

I also vaguely remember extensions to RFC3028 for sieve asking for a new
flags extension for "fileinto" action.  We could specify the implementation
dependent flag ... not sure if it is a good idea.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]