Re: [Zope] WorldPilot Calendar fixes and (UW) IMAP Options available
"RH" == Ryan Hughes <rh@n-h.net> writes:
RH> I took a look at the imap code. it basically complains that RH> the SELECTed folder is not read writable. As far as I can RH> remember the problem may be that UW IMAP locks your folders RH> when they get selected. Possibly you're accessing that folder RH> with a different client concurrently? Yes! But I think that the concurrency might be happening from Zope/WorldPilot? I.e. that it is submitting another command prior to the first results? I ran (the patched) imaplib.py by itself (it has a "sample session") which gave "reasonable" results... RH> Let me know if that's the problem, since I have heard about RH> this problem a few times, and I thought it was a locking issue RH> on UW IMAP. Or, it might be an instance of the way recent UW imap daemons deal with the maildir issue, copying files to the local user account from the mail spool... (see documentation, which I'm not yet sure that I understand; but then again, I'm a research biostatistician, not a sysadmin/www-master...). I replicated it using UW imap locally on the linux (debian) box. Maybe I'll try firing up Cyrus -- does anyone know if it "drops in" in the same way that UW Imap does? (i.e. install and go...). Debian's got it, so maybe I can do that... best, -tony -- A.J. Rossini Research Assistant Professor of Biostatistics Biostatistics/Univ. of Washington (Th) Box 357232 206-543-1044 (3286=fax) Center for AIDS Research/HMC/UW (M/F) Box 359931 206-731-3647 (3693=fax) VTN/SCHARP/FHCRC (Tu/W) Box 358080 206-667-7025 (4812=fax) rossini@(biostat.washington.edu|u.washington.edu|hivnet.fhcrc.org) http://www.biostat.washington.edu/~rossini
On Fri, 10 Mar 2000, A.J. Rossini wrote: Tony, Cyrus is most certainly NOT a drop in configuration. If you have the howto's handy there is Cyrus IMAP howto. This is definately worth reading before doing Cyrus. Jack
Maybe I'll try firing up Cyrus -- does anyone know if it "drops in" in the same way that UW Imap does? (i.e. install and go...). Debian's got it, so maybe I can do that...
best, -tony
-- A.J. Rossini Research Assistant Professor of Biostatistics Biostatistics/Univ. of Washington (Th) Box 357232 206-543-1044 (3286=fax) Center for AIDS Research/HMC/UW (M/F) Box 359931 206-731-3647 (3693=fax) VTN/SCHARP/FHCRC (Tu/W) Box 358080 206-667-7025 (4812=fax) rossini@(biostat.washington.edu|u.washington.edu|hivnet.fhcrc.org) http://www.biostat.washington.edu/~rossini
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev ) -- Jack Ungerleider The Ungerleider Group Creative Solutions for Cooperative Computing jack@jacku.com www.jacku.com
Hi Tony, "A.J. Rossini" wrote:
"RH" == Ryan Hughes <rh@n-h.net> writes:
RH> I took a look at the imap code. it basically complains that RH> the SELECTed folder is not read writable. As far as I can RH> remember the problem may be that UW IMAP locks your folders RH> when they get selected. Possibly you're accessing that folder RH> with a different client concurrently?
Yes! But I think that the concurrency might be happening from Zope/WorldPilot? I.e. that it is submitting another command prior to the first results? I ran (the patched) imaplib.py by itself (it has a "sample session") which gave "reasonable" results...
This might be possible. I'm checking the IMAP code. Possibly we'll need to use EXAMINE on some spots instead of SELECT. Maybe there's a race situation which would explain why it works for some and for some not.
RH> Let me know if that's the problem, since I have heard about RH> this problem a few times, and I thought it was a locking issue RH> on UW IMAP.
Or, it might be an instance of the way recent UW imap daemons deal with the maildir issue, copying files to the local user account from the mail spool... (see documentation, which I'm not yet sure that I understand; but then again, I'm a research biostatistician, not a sysadmin/www-master...).
I replicated it using UW imap locally on the linux (debian) box.
If heavy copy operations are involved then that would support the race situation. We use debian, too, so we'll try to replicate the behaviour here, too.
Maybe I'll try firing up Cyrus -- does anyone know if it "drops in" in the same way that UW Imap does? (i.e. install and go...). Debian's got it, so maybe I can do that...
Cyrus is better scalable and has cached indexes. furthermore mails are stored in individual files instead of in mailbox files. Cheers, Ryan
best, -tony
-- A.J. Rossini Research Assistant Professor of Biostatistics Biostatistics/Univ. of Washington (Th) Box 357232 206-543-1044 (3286=fax) Center for AIDS Research/HMC/UW (M/F) Box 359931 206-731-3647 (3693=fax) VTN/SCHARP/FHCRC (Tu/W) Box 358080 206-667-7025 (4812=fax) rossini@(biostat.washington.edu|u.washington.edu|hivnet.fhcrc.org) http://www.biostat.washington.edu/~rossini
-- Ryan Hughes <rh@n-h.net> Neuberger & Hughes GmbH http://www.n-h.net ___________________________________________________ WorldPilot Get Synched - http://www.worldpilot.org The Open Source Personal Information Manager Server Powered by Python and Zope - http://www.zope.org
Ryan Hughes wrote:
"A.J. Rossini" wrote:
> "RH" == Ryan Hughes <rh@n-h.net> writes:
RH> I took a look at the imap code. it basically complains that RH> the SELECTed folder is not read writable. As far as I can RH> remember the problem may be that UW IMAP locks your folders RH> when they get selected. Possibly you're accessing that folder RH> with a different client concurrently?
Yes! But I think that the concurrency might be happening from Zope/WorldPilot? I.e. that it is submitting another command prior to the first results? I ran (the patched) imaplib.py by itself (it has a "sample session") which gave "reasonable" results...
This might be possible. I'm checking the IMAP code. Possibly we'll need to use EXAMINE on some spots instead of SELECT. Maybe there's a race situation which would explain why it works for some and for some not.
I don't think this is a bug in WU or a concurrency issue, I think it's a funky design decision in imaplib.py Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
import imaplib server = imaplib.IMAP4('X.X.X.X') server.login('michel', '******') ('OK', ['LOGIN completed.']) server.select('Public Folders/Mailing Lists/Zope Folder') Traceback (innermost last): File "<pyshell#8>", line 1, in ? server.select('Public Folders/Mailing Lists/Zope Folder') File "C:\Program Files\Python\Lib\imaplib.py", line 468, in select raise self.readonly('%s is not writable' % mailbox) readonly: Public Folders/Mailing Lists/Zope Folder is not writable
server in this case is a Exchange box. There is nothing in section 6.3.1 of rfc2060 that says this should fail. The imaplib authors however seem to have felt otherwise, which is why there is an optional second argument to IMAP4.select(): def select(self, mailbox='INBOX', readonly=None): Passing a true value to the readonly argument will allow you to select the mailbox, as shown:
server.select('Public Folders/Mailing Lists/Zope Folder', 1) ('OK', ['964'])
-Michel
Michel Pelletier wrote:
Ryan Hughes wrote:
"A.J. Rossini" wrote:
>> "RH" == Ryan Hughes <rh@n-h.net> writes:
RH> I took a look at the imap code. it basically complains that RH> the SELECTed folder is not read writable. As far as I can RH> remember the problem may be that UW IMAP locks your folders RH> when they get selected. Possibly you're accessing that folder RH> with a different client concurrently?
Yes! But I think that the concurrency might be happening from Zope/WorldPilot? I.e. that it is submitting another command prior to the first results? I ran (the patched) imaplib.py by itself (it has a "sample session") which gave "reasonable" results...
This might be possible. I'm checking the IMAP code. Possibly we'll need to use EXAMINE on some spots instead of SELECT. Maybe there's a race situation which would explain why it works for some and for some not.
I don't think this is a bug in WU or a concurrency issue, I think it's a funky design decision in imaplib.py
Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
import imaplib server = imaplib.IMAP4('X.X.X.X') server.login('michel', '******') ('OK', ['LOGIN completed.']) server.select('Public Folders/Mailing Lists/Zope Folder') Traceback (innermost last): File "<pyshell#8>", line 1, in ? server.select('Public Folders/Mailing Lists/Zope Folder') File "C:\Program Files\Python\Lib\imaplib.py", line 468, in select raise self.readonly('%s is not writable' % mailbox) readonly: Public Folders/Mailing Lists/Zope Folder is not writable
server in this case is a Exchange box. There is nothing in section 6.3.1 of rfc2060 that says this should fail. The imaplib authors however seem to have felt otherwise, which is why there is an optional second argument to IMAP4.select():
def select(self, mailbox='INBOX', readonly=None):
Passing a true value to the readonly argument will allow you to select the mailbox, as shown:
server.select('Public Folders/Mailing Lists/Zope Folder', 1) ('OK', ['964'])
-Michel
I saw that, too, but wasn't sure if it behaves the same, because a few lines further up if that parameter is true then it uses EXAMINE instead of SELECT. I haven't made it yet back to the RFC's to check in detail what the exact difference is between the two. If EXAMINE is OK for write operations as well, then that would be fine. But it sounds like it's intended for following read only operations only. I'll check it out... Cheers, Ryan -- Ryan Hughes <rh@n-h.net> ___________________________________________________ WorldPilot Get Synched - http://www.worldpilot.org The Open Source Personal Information Manager Server Powered by Python and Zope - http://www.zope.org
Ryan Hughes wrote:
I saw that, too, but wasn't sure if it behaves the same, because a few lines further up if that parameter is true then it uses EXAMINE instead of SELECT. I haven't made it yet back to the RFC's to check in detail what the exact difference is between the two. If EXAMINE is OK for write operations as well, then that would be fine. But it sounds like it's intended for following read only operations only. I'll check it out...
Section 6.3.1...
If the client is not permitted to modify the mailbox but is permitted read access, the mailbox is selected as read-only, and the server MUST prefix the text of the tagged OK response to SELECT with the "[READ-ONLY]" response code. Read-only access through SELECT differs from the EXAMINE command in that certain read-only mailboxes MAY permit the change of permanent state on a per-user (as opposed to global) basis. Netnews messages marked in a server-based .newsrc file are an example of such per-user permanent state that can be modified with read-only mailboxes.
-Michel
participants (4)
-
Jack Ungerleider -
Michel Pelletier -
rossini＠biostat.washington.edu -
Ryan Hughes