Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

UID FETCH failed (IMAP access bug)

81 views
Skip to first unread message

add...@is.invalid

unread,
May 31, 2004, 4:15:44 PM5/31/04
to
There is a bug in how 6.1.1.1 (and 6.0.1.1) handles retrieving mail
from IMAP mailboxes. I think it has to do with updating local IMAP
mailbox files (particularly <mailbox name>.inf.) after previously
completely emptied mailbox receives the first new message.

It causes Eudora to request an out of bounds UID from the server.
Below a log of a failed exchange (some editing done to remove
irrelevant or private information):
> Sun May 30 19:14:22 2004
> Version 6.1.1.1
> LogLevel 127 (0x7F)
> 520 16:0.0 Open *.*.*.*:143
> 520 64:0.2 Rcvd: "* OK IMAP4 server (InterMail vM.6.01.03.00
> 201-2131-111-20040220) ready Sun, 30 May 2004 19:13:44 +0300 (EEST)\r\n"
> 520 32:0.2 Sent: "00000 CAPABILITY\r\n"
> 520 64:0.3 Rcvd: "* CAPABILITY IMAP4rev1 UIDPLUS NAMESPACE QUOTA\r\n"
> 520 64:0.4 Rcvd: "00000 OK CAPABILITY completed\r\n"
> 520 32:0.4 Sent: "00001 LOGIN ****** ****************\r\n"
> 520 64:0.5 Rcvd: "00001 OK LOGIN completed\r\n"
> 520 32:0.5 Sent: "00002 NAMESPACE\r\n"
> 520 64:0.5 Rcvd: "* NAMESPACE (("" "/")) NIL NIL\r\n"
> 520 64:0.6 Rcvd: "00002 OK NAMESPACE completed\r\n"
> 520 32:0.6 Sent: "00003 SELECT INBOX\r\n"
> 520 64:0.7 Rcvd: "* 4 EXISTS\r\n"
> 520 64:0.8 Rcvd: "* OK [UNSEEN 1] First unseen message\r\n"
> 520 64:0.8 Rcvd: "* OK [UIDVALIDITY 982927133] UIDs valid\r\n"
> 520 64:0.8 Rcvd: "* OK [UIDNEXT 42685] Predicted next UID\r\n"
> 520 64:0.8 Rcvd: "* FLAGS (\Answered \Flagged \Deleted \Draft \Seen)\r\n"
> 520 64:0.8 Rcvd: "* OK [PERMANENTFLAGS (\* \Answered \Flagged \Deleted
> \Draft \Seen)] Permanent flags\r\n"
> 520 64:0.8 Rcvd: "* 0 RECENT\r\n"
> 520 64:0.8 Rcvd: "00003 OK [READ-WRITE] SELECT completed\r\n"
> 520 32:0.8 Sent: "00004 FETCH 1:* (UID)\r\n"
> 520 64:0.9 Rcvd: "* 1 FETCH (UID 42681)\r\n"
> 520 64:0.9 Rcvd: "* 2 FETCH (UID 42682)\r\n"
> 520 64:0.9 Rcvd: "* 3 FETCH (UID 42683)\r\n"
> 520 64:0.9 Rcvd: "* 4 FETCH (UID 42684)\r\n"
> 520 64:0.10 Rcvd: "00004 OK FETCH completed\r\n"
> 520 32:0.10 Sent: "00005 NOOP\r\n"
> 520 64:0.10 Rcvd: "00005 OK NOOP completed\r\n"
> 520 32:0.10 Sent: "00006 FETCH 4 UID\r\n"
> 520 64:0.11 Rcvd: "* 4 FETCH (UID 42684)\r\n"
> 520 64:0.12 Rcvd: "00006 OK FETCH completed\r\n"
> 520 32:0.12 Sent: "00007 UID FETCH 42681:42684 (FLAGS UID)\r\n"
> 520 64:0.13 Rcvd: "* 1 FETCH (FLAGS () UID 42681)\r\n"
> 520 64:0.13 Rcvd: "* 2 FETCH (FLAGS () UID 42682)\r\n"
> 520 64:0.13 Rcvd: "* 3 FETCH (FLAGS () UID 42683)\r\n"
> 520 64:0.13 Rcvd: "* 4 FETCH (FLAGS () UID 42684)\r\n"
> 520 64:0.13 Rcvd: "00007 OK UID FETCH completed\r\n"
> 520 32:0.13 Sent: "00008 UID FETCH 1:42680 (FLAGS UID)\r\n"
> 520 64:0.14 Rcvd: "00008 NO UID FETCH failed\r\n"
> 520 8:0.14 Dialog: "UID FETCH failed"
> 520 8:0.14 Dialog: "Operation Failed: "
(see the fourth last line where UID 42680 is requested, when the
range offered by the server is 42681-42684)

This is a fatal error, the mailbox with this problem can't be
accessed from Eudora without repair action or switching to POP. This
is affecting several users in my company.

The workaround while waiting for this bug to be fixed is to delete
<mailbox name>.inf from
<Eudora data folder>/Imap/<personality>/<mailbox name>.
For example, from the path
C:\Program Files\Qualcomm\Eudora\Imap\Dominant\INBOX\INBOX.inf
If you have trouble finding this file, check Eudora Readme.txt from
your Eudora folder for instructions for locating your data folder
(or alternatively do a search with for example "INBOX.inf" in your
system). The file is automatically replaced by Eudora with a repaired
one when you open the mailbox next time. After that, always leave at
least one message in a server IMAP mailbox to prevent the problem
from reoccurring.

0 new messages