Custom Query (1409 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (10 - 12 of 1409)

1 2 3 4 5 6 7 8 9 10 11 12 13 14
Ticket Resolution Summary Owner Reporter
#3966 fixed IMAP delete unread message brendan anton
Description

Hi, While invoking delete-message on a unread message and then syncing the IMAP mailbox the message ends up being copied to the trash but not deleted from my local cache until I issue a second sync. Running `mutt -d5` reveals the following communication between the client and server:

Copying 1 messages to Trash...
4> a0018 UID STORE 90 +FLAGS.SILENT (\Seen)
a0019 UID COPY 90 "Trash"
4< * 6 FETCH (FLAGS (\Seen $X-ME-Annot-2) UID 90)
Handling FETCH
Message UID 90 updated
4< a0016 OK Completed
4< a0017 OK [COPYUID 1503661657 90 184] Completed
IMAP queue drained

I initially thought something was wrong with the IMAP-server since according to RFC 3501:

+FLAGS.SILENT <flag list>

Equivalent to +FLAGS, but without returning a new value.

... but it also states:

Note: Regardless of whether or not the ".SILENT" suffix was used, the server SHOULD send an untagged FETCH response if a change to a message's flags from an external source is observed.

After all this looks like a documented and valid behavior.

According to my understanding of the source code, the following is triggering the behavior I'm seeing:

  1. The unanticipated FETCH is handled by cmd_parse_fetch(). Since h->changed is true (due to the deleted flag being set and yet not synced) the IMAP context is flagged as IMAP_EXPUNGE_PENDING.
  1. imap_sync_mailbox() will not end up deleting the message since imap_check_mailbox() doesn't return 0 due to the IMAP_EXPUNGE_PENDING flag being set.
  1. Issuing a second sync will cause the message to be deleted since the local flags are in sync with the server. But this will copy the message to the trash again so I will end up with two copies of the same message in the trash.

I've been tinkering with different approaches on how to solve this issue. Here's a couple of insights and ideas:

  1. Ignoring the unanticipated FETCH inside cmd_parse_fetch() if compare_flags() == 0 doesn't work since the local flags and server flags differs.
  1. Setting h->active = 0 prior issuing the STORE/COPY IMAP-commands will cause the unanticipated FETCH to be ignored similar to what's done at the end of the imap_sync_mailbox(). With my limited knowledge of the mutt source code I cant' deduce the implications of setting active at an earlier stage.
  1. Adding a flag ignore_fetch (just as an example) to the IMAP_DATA structure and setting it 1 prior issuing the STORE/COPY could inform cmd_parse_fetch() that any FETCH should be ignored. Not the cleanest solution since it adds more state handling.

Any thoughts and ideas on how to solve this would be much appreciated.

$ mutt -v
Mutt 1.9+10 (0e0a4b7e9dd1) (2017-09-02)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: OpenBSD 6.2 (amd64)
ncurses: ncurses 5.7.20081102 (compiled with 5.7)

Compiler:
Reading specs from /usr/lib/gcc-lib/amd64-unknown-openbsd6.2/4.2.1/specs
Target: amd64-unknown-openbsd6.2
Configured with: OpenBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.1 20070719 

Configure options: '--enable-debug' '--enable-imap' '--enable-sidebar' '--with-ssl' 'CFLAGS=-g'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  -USE_SETGID  -USE_DOTLOCK  -DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
-USE_POP  +USE_IMAP  -USE_SMTP  
+USE_SSL_OPENSSL  -USE_SSL_GNUTLS  -USE_SASL  -USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  -CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET  +HAVE_LANGINFO_YESEXPR  
-HAVE_ICONV  -ICONV_NONTRANS  -HAVE_LIBIDN  +HAVE_GETSID  -USE_HCACHE  +USE_SIDEBAR  -USE_COMPRESSED  
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/local/share/mutt"
SYSCONFDIR="/usr/local/etc"
EXECSHELL="/bin/sh"
-MIXMASTER
To contact the developers, please mail to <mutt-dev@mutt.org>.
To report a bug, please visit http://bugs.mutt.org/.
#3965 fixed mutt-1.9.0/mutt_ssl_gnutls.c:650]: (error) Resource leak: fp mutt-dev dcb314
Description

Source code is

if ((fp = fopen (SslCertFile?, "r"))) {

if (REGCOMP(&preg, "#H ([a-zA-Z0-9_
.-]+) ([0-9A-F]{4}( [0-9A-F]{4}){7})[ \t]*$",

REG_ICASE) != 0)

{

return 0;

}

Other paths through the code have calls to

safe_fclose (&fp);

Maybe such a call is needed here ?

#3964 fixed mutt-1.9.0/curs_lib.c:668]: (style) Suspicious condition mutt-dev dcb314
Description

mutt-1.9.0/curs_lib.c:668]: (style) Suspicious condition (assignment + comparison); Clarify expression with parentheses.

Source code is

if ((rv = mutt_window_move (win, row, col) != ERR))

Maybe better code

if ((rv = mutt_window_move (win, row, col)) != ERR)

1 2 3 4 5 6 7 8 9 10 11 12 13 14
Note: See TracQuery for help on using queries.