Re: Added ~/.<program>rc as a config file.

[Sam Roberts]

Quoteing address@hidden, on Fri, Mar 22, 2002 at 01:58:05PM +0200:
> Well, basically, imap4d allows to access mailboxes in three separate
> namespaces: a) user's private namespace, where the user usually has
> all the rights over the files, b) shared namespace, which may or may
> not be writable by the user and c) other namespace, which is generally
> not writable neither for the user nor for the group. The setup is
> described in detail in RFC 2342. The problem arises when imap4d is
> trying to open (and consequently lock) a mailbox which is located
> in other (and sometimes in shared) namespace.

Alain convinced me that I should add back the flag to locker_lock()
that indicates whether it is a read or write lock. Then you can
set a flag indicating whether a file should actually be dot-locked
when reading. This would allow fast (non-) locking when just
reading a file, and real locking when writing.

> > My spool was writeable only by group mail, I had to change that to
> > use mailutils to open my spool file. I want to add a flag to the
> > locker that will cause the locker to behave the same, but call dotlock 
> > instead of doing the locking itself. dotlock can be setgid mail,
> > or setuid root, and it will lock the file even in a directory the
> > user doesn't have write permission to (after appropriate permissions
> > checks).
> > 
> > Will this address the problem you're talking about?
> 
> I guess it will. Do you plan to make the path to dotlock
> hardcoded, or specifiable via a command-line option?

Working on this now, hopefully committed this evening.

Default is "dotlock". Settable with locker_set_external(),
and I'll add a locker_set_external_default() to override the
default, and add a --dotlock-external[=PROGRAM] that calls
it.

Ok for you?

Sam

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)