Summary | delete action does not update mailbox in traditional view |
Queue | IMP |
Queue Version | Git master |
Type | Bug |
State | Not A Bug |
Priority | 1. Low |
Owners | slusarz (at) horde (dot) org |
Requester | leena.heino (at) uta (dot) fi |
Created | 03/29/2012 (4830 days ago) |
Due | |
Updated | 04/19/2012 (4809 days ago) |
Assigned | 04/03/2012 (4825 days ago) |
Resolved | 04/19/2012 (4809 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
As a workaround I used these settings in backends.local.php:
'cache' => true,
'debug' => '/dev/null',
be able to compare the logs.
AUTH=LOGIN XIMAPPROXY] Dovecot ready.
C: [LOGIN Command - username: slusarz]
S: * OK [XPROXYREUSE] IMAP connection reused by squirrelmail-imap_proxy
S: 1 OK User logged in
C: 2 SELECT Testing.AAC (QRESYNC (1255685589 148 50:76,78:103,106))
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft impflag0
$Forwarded impflag1)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft
impflag0 $Forwarded impflag1 \*)] Flags permitted.
S: * 54 EXISTS
S: * 0 RECENT
S: * OK [UNSEEN 2] First unseen.
S: * OK [UIDVALIDITY 1255685589] UIDs valid
S: * OK [UIDNEXT 107] Predicted next UID
S: * OK [HIGHESTMODSEQ 148] Highest
S: 2 OK [READ-WRITE] Select completed.
S: * 6 FETCH (UID 55 MODSEQ (149))
S: 3 OK Store completed.
successfully updated]
search queries are no longer valid so we need to remove those also]
S: * ESEARCH (TAG "4") UID ALL
50,79,51,80,52,81,53,82,54,83,55,84,56,85,57,86,58,87,59,88,60,89,61,90,62,91,63,92,64,93,65,94,66,95,67,96,68,97,69,98,70,99,71,100,72,101,73,102,74,103,75,78,106,76 COUNT
54
S: 4 OK Sort completed (0.000 secs).
98367107759a917e62e60584c8d69c2f)
S: * 6 FETCH (UID 55 MODSEQ (149))
S: 5 OK Fetch completed.
S: * OK [CLOSED] Previous mailbox closed.
S: * BYE LOGOUT received
S: 6 OK Completed
Here's the undelete action immediately after:
AUTH=LOGIN XIMAPPROXY] Dovecot ready.
C: [LOGIN Command - username: slusarz]
S: * OK [XPROXYREUSE] IMAP connection reused by squirrelmail-imap_proxy
S: 1 OK User logged in
C: 2 SELECT Testing.AAC (QRESYNC (1255685589 149 50:76,78:103,106))
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft impflag0
$Forwarded impflag1)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft
impflag0 $Forwarded impflag1 \*)] Flags permitted.
S: * 54 EXISTS
S: * 0 RECENT
S: * OK [UNSEEN 2] First unseen.
S: * OK [UIDVALIDITY 1255685589] UIDs valid
S: * OK [UIDNEXT 107] Predicted next UID
S: * OK [HIGHESTMODSEQ 149] Highest
S: 2 OK [READ-WRITE] Select completed.
C: 3 UID STORE 55 (UNCHANGEDSINCE 149) -FLAGS.SILENT \deleted
S: * 6 FETCH (UID 55 MODSEQ (150))
S: 3 OK Store completed.
S: * OK [CLOSED] Previous mailbox closed.
S: * BYE LOGOUT received
S: 4 OK Completed
(regardless of the debug setting), the flag changes are still
correctly saved in the cache.
So this behavior is only being seen on your server, which means you
will need to track down the issue further.
be able to compare the logs.
Which server are you testing against?
Priority ⇒ 1. Low
(regardless of the debug setting), the flag changes are still
correctly saved in the cache.
So this behavior is only being seen on your server, which means you
will need to track down the issue further.
New Attachment: imap-cache-debug.txt
debug mode.
on caching done by Horde_Imap_Cache.
- if I enable debug mode in backends.local.php then the problems
disappear and flags are updated correctly
- If I disable debug mode in backends.local.php then the problems
reappear and every flag changing operation has to be done twice.
Are the any other differences between these modes in IMAP protocol
level other than one uses FLAGS and the other uses FLAGS.SILENT?
caching done by Horde_Imap_Cache.
New Attachment: imap-cache.txt
Assigned to Michael Slusarz
opinion this might not a problem with Cyrus, but if you use
FLAGS.SILENT and don't get an error, you need to update your local
cache.
$this->_sendLine($cmd);
$this->_storeUpdateCache('replace', $options['replace']);
[...]
$this->_sendLine($cmdtmp);
$this->_storeUpdateCache($k, $options[$k]);
If the command executes correctly on the IMAP server ($this->_sendLine
will throw an Exception on a BAD/NO response from the server), the
cache is updated with the changes.
It goes without saying that this works fine for me, whether IMAP
debugging is turned on or off (this toggles whether FLAGS or
FLAGS.SILENT is sent).
Bug #11118)Bug #11118)opinion this might not a problem with Cyrus, but if you use
FLAGS.SILENT and don't get an error, you need to update your local
cache.
Included is imap-cache.txt: Cache is enabled in IMP and example user
does this:
1. Open mailbox
2. Mark message as deleted -> flag change is not shown on the screen
3. Mark message again as deleted -> now message is shown as deleted
4. Mark message as undeleted -> deleted flag is still shown on the screen
5. Mark message as undeleted -> now deleted flag is no longer seen on
the screen
6. Logout
communication.
enabled in IMP and when cache is disabled.
I can include the logs here with this bug. But I would prefer that
these logs are only available to developers.
bug #11118?unseen count is not being updated correctly.
To further debug this issue, we need details of the IMP -> IMAP/POP
communication.
To enable debugging, see instructions contained in
imp/config/backends.php (the 'debug' config parameter).
Debugging should not be enabled on a production server, Attach/post
only the portion of the log that directly deals with the problem
reported (it may be simplest to clear the log file and then perform
the event that causes the error).
bug #11118?bug #11118?This seems to be related to the way cache works. As this happens
rarely when cache => false in backends.php, but it happens really
often when cache => true.
State ⇒ Feedback
bug #11118?IMAP Server: Cyrus IMAPD 2.4.14
Priority ⇒ 2. Medium
State ⇒ Unconfirmed
Patch ⇒ No
Milestone ⇒
Summary ⇒ delete action does not update mailbox in traditional view
Type ⇒ Bug
Queue ⇒ IMP
view or message status is not updated and the message is still shown
as not deleted. If user does folder refresh or does the same mark as
delete operation again, then the message status is updated as deleted.
This does not happen when the delete status is removed from the
message. Then the folder view or message status is updated immediately.
How to reproduce situation:
1. log in to imp in traditional mode
2. mark message as deleted
3. message status in the folder view is not updated