flag "trashed" not recognized?

[Alan Schmitt]

Hello,

As I was trying to find out how to deal with the trashed flag on my imap
server, I think I've discovered a bug with mu4e.

I have many trashed messages in my mailbox:

~/.Maildir/INBOX ls new
1364933080_0.92474.top.local,U=657542,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,T
1364933080_1.92474.top.local,U=657537,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,T
1364933080_2.92474.top.local,U=657511,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,T
1364933081_4.92474.top.local,U=657524,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,T
1364933081_7.92474.top.local,U=657527,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,T
...

(Question: am I mistaken by interpreting the 'T' as meaning trashed?)

Unfortunately, when I restrict my view to trashed messages ("/
flag:trashed"), no message is displayed. Does this mean that mu4e does
not correctly recognized trashed messages? (In the interface, these
messages have the flag "Nu" and do not mention "T".)

I'm using mu4e recompiled from git this morning.

Thanks,

Alan

[Dirk-Jan C. Binnema]

On Wed, Apr 03 2013, Alan Schmitt wrote:

> Hello,
>
> As I was trying to find out how to deal with the trashed flag on my imap
> server, I think I've discovered a bug with mu4e.
>
> I have many trashed messages in my mailbox:
>
> ~/.Maildir/INBOX ls new
> 1364933080_0.92474.top.local,U=657542,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,T
> 1364933080_1.92474.top.local,U=657537,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,T
> 1364933080_2.92474.top.local,U=657511,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,T
> 1364933081_4.92474.top.local,U=657524,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,T
> 1364933081_7.92474.top.local,U=657527,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,T
> ...

Well, messages in new/ shouldn't have any flags (as per the maildir
spec), so mu explicitly ignores them.

> (Question: am I mistaken by interpreting the 'T' as meaning trashed?)
>
> Unfortunately, when I restrict my view to trashed messages ("/
> flag:trashed"), no message is displayed. Does this mean that mu4e does
> not correctly recognized trashed messages? (In the interface, these
> messages have the flag "Nu" and do not mention "T".)

At least for me, trashed messages are handled fine; maybe there's a bug
somewhere else that puts those messages in new/.

Best wishes,
Dirk.


--
Dirk-Jan C. Binnema Helsinki, Finland
e:dj...@djcbsoftware.nl w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C

[Alan Schmitt]

Dirk-Jan C. Binnema writes:

> Well, messages in new/ shouldn't have any flags (as per the maildir
> spec), so mu explicitly ignores them.

Ah, good to know.

> At least for me, trashed messages are handled fine; maybe there's a bug
> somewhere else that puts those messages in new/.

Yes, I suspect it's either the server or offlineimap. As this bug comes
and goes, it's difficult to track down.

Thanks again,

Alan

[Alan Schmitt]

Hello,

I realized that the problem I had reported in a recent thread was
related to this.

Dirk-Jan C. Binnema writes:

> On Wed, Apr 03 2013, Alan Schmitt wrote:
>
>> Hello,
>>
>> As I was trying to find out how to deal with the trashed flag on my imap
>> server, I think I've discovered a bug with mu4e.
>>
>> I have many trashed messages in my mailbox:
>>
>> ~/.Maildir/INBOX ls new
>> 1364933080_0.92474.top.local,U=657542,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,T
>> 1364933080_1.92474.top.local,U=657537,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,T
>> 1364933080_2.92474.top.local,U=657511,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,T
>> 1364933081_4.92474.top.local,U=657524,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,T
>> 1364933081_7.92474.top.local,U=657527,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,T
>> ...
>
> Well, messages in new/ shouldn't have any flags (as per the maildir
> spec), so mu explicitly ignores them.

I think this is a bug with offlineimap. I have asked the offlineimap
list about it, but there is very little traffic. In the meantime, could
it be possible for mu4e to recognize these flags?

Alternatively, I could migrate do mbsync (which does not have this
problem), but for this mu4e needs to avoid reusing file names when
moving messages around (https://github.com/djcb/mu/issues/146).

Thanks,

Alan

[Dirk-Jan C. Binnema]

Hi Alan,

On Wed, May 15 2013, Alan Schmitt wrote:

> I realized that the problem I had reported in a recent thread was
> related to this.
>
> Dirk-Jan C. Binnema writes:
>
>> On Wed, Apr 03 2013, Alan Schmitt wrote:
>>
>>> Hello,
>>>
>>> As I was trying to find out how to deal with the trashed flag on my imap
>>> server, I think I've discovered a bug with mu4e.
>>>
>>> I have many trashed messages in my mailbox:
>>>
>>> ~/.Maildir/INBOX ls new

>> 1364933080_0.92474.top.local,U=657542,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,T
>>> 1364933080_1.92474.top.local,U=657537,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,T

>> Well, messages in new/ shouldn't have any flags (as per the maildir
>> spec), so mu explicitly ignores them.
>
> I think this is a bug with offlineimap. I have asked the offlineimap
> list about it, but there is very little traffic. In the meantime,
> could it be possible for mu4e to recognize these flags?

I don't really want to change that... but it should be easy to get rid
of those message with some python from the offlineimap configuration?
Or, alternatively, with a shellscript that calls offlineimap, then
deletes the unwanted messages?

> Alternatively, I could migrate do mbsync (which does not have this
> problem), but for this mu4e needs to avoid reusing file names when
> moving messages around (https://github.com/djcb/mu/issues/146).

You make it sound like a bug, it's a feature!

[James Ladan]

On Wednesday, 15 May 2013 11:49:06 UTC-7, djcb wrote:

> Alternatively, I could migrate do mbsync (which does not have this
> problem), but for this mu4e needs to avoid reusing file names when
> moving messages around (https://github.com/djcb/mu/issues/146).

You make it sound like a bug, it's a feature!

Would you mind explaining what makes it a feature for you? I would vote "bug" because it conflicts horribly with mbsync and mutt renames when moving (I installed mutt specifically to test this). 

I'd submit a suggested patch/idea that at least makes it configurable, but I'm getting by working around it for now (using Gmail web interface) and don't have much spare time at the moment. :(  Actually, a maybe overly complicated solution would be: if .mbsyncstate or .uidvalidity are present in any maildir, then rename the file on move.

Thanks,
James.

[Dirk-Jan C. Binnema]

On Wed, May 15 2013, James Ladan wrote:

> On Wednesday, 15 May 2013 11:49:06 UTC-7, djcb wrote:
>
>> > Alternatively, I could migrate do mbsync (which does not have this
>> > problem), but for this mu4e needs to avoid reusing file names when
>> > moving messages around (https://github.com/djcb/mu/issues/146).
>>
>> You make it sound like a bug, it's a feature!
>>
>
> Would you mind explaining what makes it a feature for you? I would vote
> "bug" because it conflicts horribly with mbsync and mutt renames when
> moving (I installed mutt specifically to test this).

Well, the 'feature' is that mu is not gratuitously renaming files when
moving them, so I can keep track of them based on their name. It's been
like that since forever, so I'm not too keen on changing that, since it
may break other things.

> I'd submit a suggested patch/idea that at least makes it configurable, but
> I'm getting by working around it for now (using Gmail web interface) and
> don't have much spare time at the moment. :( Actually, a maybe overly
> complicated solution would be: if .mbsyncstate or .uidvalidity are present
> in any maildir, then rename the file on move.

Well, if it's a small change, and configurable, I can take a look.

[James Ladan]

On Wednesday, 15 May 2013 14:26:37 UTC-7, djcb wrote:

> Would you mind explaining what makes it a feature for you? I would vote
> "bug" because it conflicts horribly with mbsync and mutt renames when
> moving (I installed mutt specifically to test this).

Well, the 'feature' is that mu is not gratuitously renaming files when
moving them, so I can keep track of them based on their name. It's been
like that since forever, so I'm not too keen on changing that, since it
may break other things.

Fair enough. :) 

> I'd submit a suggested patch/idea that at least makes it configurable, but
> I'm getting by working around it for now (using Gmail web interface) and
> don't have much spare time at the moment. :(  Actually, a maybe overly
> complicated solution would be: if .mbsyncstate or .uidvalidity are present
> in any maildir, then rename the file on move.

Well, if it's a small change, and configurable, I can take a look.

Now to find/make the time... and find out whether or not it breaks other things!

Thanks,
James.

[Alan Schmitt]

Dirk-Jan C. Binnema writes:

>>> Well, messages in new/ shouldn't have any flags (as per the maildir
>>> spec), so mu explicitly ignores them.
>>
>> I think this is a bug with offlineimap. I have asked the offlineimap
>> list about it, but there is very little traffic. In the meantime,
>> could it be possible for mu4e to recognize these flags?
>
> I don't really want to change that... but it should be easy to get rid
> of those message with some python from the offlineimap configuration?
> Or, alternatively, with a shellscript that calls offlineimap, then
> deletes the unwanted messages?

This is what I ended up doing (a small shell script, I don't know how to
hook into offlineimap directly).

>> Alternatively, I could migrate do mbsync (which does not have this
>> problem), but for this mu4e needs to avoid reusing file names when
>> moving messages around (https://github.com/djcb/mu/issues/146).
>
> You make it sound like a bug, it's a feature!

Well, it's considered a bug on the mbsync list, and because of some
carelessness of me, I lost some emails because of it ...

Alan