Virtual folders of IMAP folders can't get new mail

[Uday Reddy]

This problem occurred twice, using Emacs 22. Doing a get new mail in an IMAP folder ended up getting multiple copies, apparently in an infinite loop. The *Messages* buffer shows the following sequence being repeated:

Checking for new mail for d:/Home/udr/mail/cache/imap-cache-edb15217b986b74f2751726a69a193f6...
Logging into the IMAP server...
Updating attributes on the IMAP server... done
Retrieving message attributes and labels...
Retrieving message atrributes and labels... done
Retrieving new messages...
Updating summary...
Sorting... done
3859 messages, 17 new, 207 unread, 6 deleted
Decoding MIME message...
Inlining text/html by emacs-w3m...
Decoding base64... done
Inlining text/html by emacs-w3m... done.
Decoding MIME message... done
3859 messages, 17 new, 207 unread, 6 deleted
Checking for new mail for d:/Home/udr/mail/cache/imap-cache-edb15217b986b74f2751726a69a193f6...

Eventually, Decoding base64 line is followed by

Inline text/html by emacs-w3m display failed: (error "Variable binding depth exceeds max-specpdl-size")
Decoding MIME message... done
3882 messages, 40 new, 207 unread, 6 deleted
Checking for new mail for d:/Home/udr/mail/cache/imap-cache-edb15217b986b74f2751726a69a193f6...
Logging into the IMAP server...
Updating attributes on the IMAP server... done
Retrieving message attributes and labels...
Retrieving message atrributes and labels... done
Retrieving new messages...
Updating summary...
Sorting... done
font-lock-extend-jit-lock-region-after-change: Variable binding depth exceeds max-specpdl-size

9 copies of the retrieved messages appear in the INBOX. All of them have 0 as the size.

9 IMAP sessions have been created and destroyed, and a final one created in the end but not terminated.

The messages in the INBOX have

body-to-be-discarded = t
body-to-be-retrieved = nil
uid = nil
uidvalidity = nil
spam-score = nil

[Uday Reddy (reddyuday)]

debug-on-entry shows the following. Why is vm-imap-synchronize-folder being entered recursively?

* vm-imap-synchronize-folder(t nil t t t t)
  vm-get-spooled-mail(t)
  byte-code(... 10)
  vm("d:/Home/udr/mail/cache/imap-cache-edb15217b986b74f2751726a69a193f6" nil nil)
  vm-visit-folder("d:/Home/udr/mail/cache/imap-cache-edb15217b986b74f2751726a69a193f6")
  vm-build-virtual-message-list(...)
  vm-assimilate-new-messages(t)
  byte-code(... 9)
* vm-imap-synchronize-folder(t nil t t t t)
  vm-get-spooled-mail(t)
  vm-get-new-mail(nil)
  call-interactively(vm-get-new-mail)

[Uday Reddy (reddyuday)]

The problem seems to be that there is a virtual folder based on the IMAP folder. Its definition says that it is actually based on the corresponding cache-folder on the disk. So, vm-build-virtual-message-list is trying to visit that folder. Craziness!

[Uday Reddy (reddyuday)]

Couldn't reproduce this problem today. Even though the virtual folder definition is based on the cache-folder, since the folder is already loaded into a buffer, visiting the folder merely switches to the buffer. Why was this supposed to be a problem?

[Uday Reddy (reddyuday)]

It is a problem because visiting the folder gives enters it in an inconsistent state.

The revision 966 avoids this in some cases. Not clear if this works in general.

[Uday Reddy (reddyuday)]

Another instance of the problem found today:

Build a virtual folder based on an IMAP folder, and do get-new-mail in the IMAP folder. This ends up calling vm-build-virtual-message-list for the virtual folder, which calls vm-visit-folder on the IMAP folder. This tries to present a message, which involves vm-retrieve-real-message-body. Since the folder is still in an inconsistent state, this fails. (In particular, the uid field of the message vector is not defined yet.)

[Uday Reddy (reddyuday)]

This is now fixed in revision 1194.

vm-visit-folder now has an extra argument `revisit', which allows the folder to be revisited in a lightweight fashion without doing further processing in its inconsistent state.

[Uday Reddy (reddyuday)]

Continued in Bug 614413.

[Uday Reddy (reddyuday)]

That should have said, continued in Bug 924016.

[Uday Reddy (reddyuday)]

Revision 1310 has a stray edit that continues the fix for this problem.