#735261 kmail2 randomly marks read messages as unread

Package:
kmail
Source:
kmail
Description:
full featured graphical email client
Submitter:
Shai Berger
Date:
2015-01-18 23:36:18 UTC
Severity:
important
#735261#5
Date:
2014-01-14 08:40:48 UTC
From:
To:
Dear Maintainer,

KMail randomly marks single messages as unread. This makes my
normal workflow, where I leave messages unread for later, deeper
consideration, tedious and bordering on impossible.

KMail also randomly creates new duplicates of old messages, which
are (of course) also marked unread.

After an safe-update which included Akonadi, I found duplicates
for 400 such messages.

Losing "read" status is data loss.
#735261#10
Date:
2014-01-20 16:14:19 UTC
From:
To:
Hi, I'm not sure if your problem is like mine

using kmail with imap, I see coming new messages and suddenly disappear
it.. so I lost messages...

this keep kmail useless

thanks for help
#735261#15
Date:
2014-11-01 04:34:56 UTC
From:
To:
Is this still an issue with the current kmail (4.14) or akonadi (1.13)?

Scott K
#735261#20
Date:
2014-11-01 12:29:06 UTC
From:
To:
found 735261 kdepim/4:4.14.2-2


Hello,

also in 4:4.14.2-2.


CU
Jörg
#735261#27
Date:
2014-11-09 09:13:54 UTC
From:
To:
The issue went on-and-off over a lot of time, and in the end I've given up on
trusting kmail2 with my read/unread marks; so it was hard to me to answer
immediately.

That said, in the last week there seem to be no spurious duplicates or unread
markings.

Thanks,
	Shai.
#735261#32
Date:
2014-12-13 11:21:55 UTC
From:
To:
Hey,

it is hard to descide witch upstream bug matches best:
https://bugs.kde.org/show_bug.cgi?id=276856
https://bugs.kde.org/show_bug.cgi?id=288208
https://bugs.kde.org/show_bug.cgi?id=278737
https://bugs.kde.org/show_bug.cgi?id=294074
https://bugs.kde.org/show_bug.cgi?id=285063

I think the underlying problem is a race condition between sync with the sever
and kmail. So if you mark a message when akonadi is performing a sync, the
read status will be updated first from kmail and the overwritten by akonadi
sync -> kmail read status is lost.

Molstly this problem is related with very big folders.

Regads,

sandro
#735261#37
Date:
2014-12-20 02:20:14 UTC
From:
To:
These kinds of problems have plagued kmail for many, many years, dating
back to the beginnings of kmail2 (at least). As we can see from the
numerous upstream bugs, there is also no shortage of reports (IIRC, I
filed one myself for fake duplicates years ago). Perhaps upstream
doesn't care, or it's really rare and difficult to reproduce or fix, I
don't know.

It may sound cynical, but my advice would be that if you're hit with
this, change mail clients :/

In the context of freeze/release, I'd suggest to tag this jessie-ignore,
or even forever-ignore.
#735261#40
Date:
2014-12-20 02:20:14 UTC
From:
To:
These kinds of problems have plagued kmail for many, many years, dating
back to the beginnings of kmail2 (at least). As we can see from the
numerous upstream bugs, there is also no shortage of reports (IIRC, I
filed one myself for fake duplicates years ago). Perhaps upstream
doesn't care, or it's really rare and difficult to reproduce or fix, I
don't know.

It may sound cynical, but my advice would be that if you're hit with
this, change mail clients :/

In the context of freeze/release, I'd suggest to tag this jessie-ignore,
or even forever-ignore.
#735261#45
Date:
2015-01-14 02:45:16 UTC
From:
To:
control: severity -1 important

This is a usability problem, so it doesn't really qualify as release critical.

Best wishes,
Mike
#735261#52
Date:
2015-01-15 00:08:17 UTC
From:
To:
Hi Michael,
Debian developers get to call the severity of bugs in general, and the
criticality for a specific release in particular.

However, the problem reported here is not a usability problem. If a mail
client losing record of which mails have been read and which haven't isn't
"non-serious data loss", I can't tell what is.

Respectfully,

Shai.
#735261#57
Date:
2015-01-15 23:45:53 UTC
From:
To:
Actual data loss.

Best wishes,
Mike
#735261#62
Date:
2015-01-16 13:07:34 UTC
From:
To:
So, the bits marking messages as "read" or "unread" are not data? What, pray
tell, are they?
#735261#71
Date:
2015-01-18 19:46:52 UTC
From:
To:
Easily recreatable bit flags.

Best wishes,
Mike
#735261#76
Date:
2015-01-18 21:14:29 UTC
From:
To:
So data isn't lost if it is "easily recreatable"? Really?

By that argument, there really shouldn't be any data loss bugs, because all
data should be easily restorable from backup.

Those "easily recreatable" bits represent a significant part of my mail
workflow. Almost any data can be recreated by repeating the work that created
it. Your claims essentially come down to "workflows based on 'read status' are
invalid or unimportant". Well, they're damned important to me.

I suspect that this discussion is going nowhere, but I still would like you to
answer one more question: Can you describe the difference between "serious" and
"non-serious" data loss?

Thanks,
	Shai.
#735261#81
Date:
2015-01-18 21:51:01 UTC
From:
To:
No.

Also no.

Then you're either choosing the wrong mail client or not doing enough
to help upstream scratch that itch.

The difference is "actual" vs. "perceived" data loss.

Best wishes,
Mike
#735261#86
Date:
2015-01-18 22:44:12 UTC
From:
To:
Certainly; but that's hardly what we're discussing here.

I am asking about "serious" vs. "non-serious" because those are the terms used
by reportbug ("non-serious data loss" is a reason to mark a bug "grave").

Calling data-loss which you find unimportant "perceived, not  actual" isn't
helpful at all. You're playing with terms rather than making points.

Shai.
#735261#91
Date:
2015-01-18 22:54:41 UTC
From:
To:
Both grave and critical refer to actual data loss.  Using the term
serious isn't particularly useful since that falls outside those two
categories anyway.
important severity.

The description of the "important" may help correct the ongoing misperception:
https://www.debian.org/Bugs/Developer#severities

Best wishes,
Mike
#735261#96
Date:
2015-01-18 23:18:48 UTC
From:
To:
Again, you're being tautological, repeating your terms rather than defining
them.

In my book, "a major effect on the usability of a package" means I can't do
what I want (easily enough). The case here -- "I told the program something
and it forgot it" -- is data loss.

Your answers above indicate that "easy recreatability" does not make something
"not data loss"; and yet this case is not data loss because it is just "easily
recreatable bits". The only interpretation I find consistent with that is
"single bits are not data" -- which makes no sense to me.

Thanks for your patience,
	Shai.
#735261#101
Date:
2015-01-18 23:34:51 UTC
From:
To:
Without some form of tautology, everyone's favorite itch would get the
highest severity.  Nothing would get done that way, so the project
created roughly defined bug severities.  Unfortunately language is not
black and white, so often enough people come along with perceptions
that differ from the project at large, and these kinds of discussion
ensue without productively accomplishing anything.

The program can't do read/unread flags correctly.  That falls under
the first category.  Never did it forget the actual content of the
mail, which would be actual data loss.

Unfortunately, this itch isn't severe enough to block the upcoming
release.  If it somehow gets fixed in the meantime, you can always
plea your case to the release team to consider accepting it.

Can we please move on?

Best wishes,
Mike