----- Original Message ----- 
From: "Mark Crispin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 07, 2004 6:09 PM
Subject: Re: File Locking


> On Wed, 7 Jul 2004 [EMAIL PROTECTED] wrote:
> > You say IMAP Server is based on C-Client and c-client locking is only of
> > interest to concurrent non-c-client applications...
> > How then does it NOT apply to IMAP access?
>
> An IMAP application uses IMAP protocol.  It does not concern itself with
> what the server does internally.

I understand now. I was thinking of IMAP "access" to the data concurrently
with POP and SMTP access to the data.


> > Doesn't accessing IMAP mean you are using c-client. If you were
concurrently
> > accessing the file with another application my understanding from what
you
> > said above is that file locking WOULD then be a concern.
> What?  You allow shell access on your IMAP server systems?

No - by other application I meant POP or SMTP


> > For example I can't seem to determine whether cucipop also uses
c-client,
> > but if it does not and accesses a mail file concurrently with the IMAP
> > server, that would describe the situation in the document right?
>
> Why use cucipop?  Why not use ipop3d, which is bundled with UW imapd?

:) I really don't know. I'll have to ask. That is something I'm not familiar
with. I may be revealing my ignorance again, but I think we were using
qpopper before we even decided to use IMAP at all, that had problems over
NFS because it locks, makes a copy and if you are saving messages on the
server copies it back. All that happening over NFS doubled our I/O
requirements. cucipop doesn't make a copy so we began to use it. Shortly
thereafter we decided to also include IMAP access to "reduce POP I/O
traffic" and now IMAP access has become a value-added service.
I'll have to look in to ipop3d. Does it make a temporary working copy, and
then write back to the mbox when it is done?
does it have a mailing list on which it would be more appropriate to discuss
these things?


>
> -- Mark --
>
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.
>

Reply via email to