[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#350851: kmail: More mail loss :(



On Friday 29 December 2006 04:37, Ana Guerrero wrote:
> tags 350851 +fixed-upstream
> notfound 350851 4:3.5.5.dfsg.1-4
> close 350851 4:3.5.5-1
> thanks
>
> On Thu, Dec 28, 2006 at 07:06:16PM -0600, Adam Porter wrote:
> [...]
>
> > I hate to be the bearer of bad news, but KMail still has this problem. 
> > (Or maybe this is actually a separate bug caused by a separate problem,
> > but the end result is still mail loss in disconnected IMAP accounts.)
>
> Sorry Adam, we (KDE team) have been discussing this and we think this bug
> is fixed. Since this bug was fixed in october only you has reported this
> problem again. Also, after read your mail, it does not seem you have
> exactly the same problem neither.
> So, i'm closing the bug and you always can open a new one if you find out
> what it is exaclty the problem.
>
> P.S: btw, perhaps you could use /dev/input/mice instead?

This is very disappointing.  I just lost eight e-mails completely from my 
dIMAP account; they're just gone.  Other people on the KDE bug tracker also 
reported the "No Subject" e-mails in the same KDE bug report.  Not only was 
my local copy erased, but KMail erased the copy on the server as well.  Were 
it not for my forwarding e-mails to GMail before they land in my inbox, I'd 
never see those e-mails again.  There's absolutely no way to recover them.

So I just don't understand how you can claim the bug is fixed, when I just 
experienced exactly what the bug reports: data loss with disconnected IMAP 
account.  Clearly, KMail's dIMAP account support is still not completely 
trustworthy.

And how will opening a new bug report do any good?  People who have an 
interest in this problem are already subscribed to these bug reports.  
Opening a new one will just make it that much less likely for them to find 
out that the problem still exists.

Please reconsider your decision and reopen this bug.  At the very least, 
people need to be aware that the problem still exists.

P.S.  Thank you for your suggestion, but /dev/input/mice does not use the 
evdev driver.  I think there is a way to configure udev to assign the same 
eventX device every time, but I haven't been successful in doing so yet.

Attachment: pgplm0lxht0sa.pgp
Description: PGP signature


Reply to: