lstroyan, in GMail there are only three folders; All Mail, Trash and Spam, everything else are virtual folders. So a message in Inbox is actually just a message in All Mail with an Inbox label. Moving a message from one virtual folder like Inbox to another virtual folder like Sent, is just a label change. Moving a message from Inbox to Trash is an actual folder change.
Georg, that is a very specific trigger. Now I understand why I am not able to reproduce it. I have never deleted, undo, deleted then undo again on the same message. Some indecision going on there?
Nah, no indecision here, just testing delete/undelete behavior - doesn’t have to be the same message either. All I was saying is that the first message I try to undelete after starting emClient or coming back after a while from other work sometimes sticks (i.e. comes back). Once I do the same with another message - or for the heck of it with the same message I can reproduce the bug.
I usually don’t use the function anymore for the above reasons, just when the discussion comes up or a new update (I just tested it on 7.1.33101.0) then I try it with different messages in different accounts for which I’m sure I don’t need them anymore… at some point you run out of messages to test with delete/undelete if they disappear forever …
I actually may go back to outlook and a third party calendar sync add-on. GApps sync for business, which I used before has a size limit (you need to set a sync size) that creates issues for me, which originally made me search for an alternative IMAP client that has full calendar support -> which I thought was emClient …
Regardless of folder change versus label change, my point remains that what we call delete is really not a delete but a move or re-categorization, to a folder named Trash. If users permanently lost an email thread every time they moved it to a folder and then changed their mind, there would be no doubt people would consider it a bug. This folder just has the additional meaning of Trash, which different users will use differently.
But the way, this bug has happened every time I’ve tested it, but since I leave emclient open for days or weeks at a time, it’s possible that the first occasion works/doesn’t exhibit the defect, and that I didn’t notice.
Ok - here’s an update what I heard back from the developers:
It seems that messages are discarded because of the server bug which occurs whenserveris accessed by multiple connections simultaneously. Here is what log says:
Messageis copied from INBOX to trash firs. Its assigned unique ID in Trash is “1803”.
Afterwardsit’s deleted from INBOX.
Then eM Client tries to movemessagefrom Trash to INBOX using another connection. Now,serveris not aware of the message being in Trash at this point so the action is ignored (see “No messages found”). However, it didn’t return any error and at the sametimeit returned that some new messages were added to Trash ("* 12 EXISTS").
At the last step eM Client removesmessagefrom trash becauseserverdidn’t notifyclientthat copying has failed at earlier steps.
I then asked back what this means for me - this is their answer:
I’m afraid that we are not able to assist you with server configuration as it is out of our support scope. At thispointwe have located the issue and according to logs it’s server-side issue so changes to server setting may be requiredhowever_, I would recommend contacting server hosting company support for further assistance as they may already_ receivedsimilar reports.
So for me that’s it. This means they are not addressing it as a bug, since they claim this happens on my email servers - funny thing is:
I’ve tested this with four different email services across different hosts and servers.
This is CLEARLY an issue of emClient with the process as other clients can work with this “Server Configuration”.
It may have to do with my super fast connection and hardware configuration that it doesn’t occur for other users, but that shouldn’t be an excuse for developers.
I’ll probably go back to Outlook and pay for a sync service since GApps for business has a size limit that I need to set for the sync file and which then doesn’t load older messages anymore when I exceed the limit (but at least they are still on Gmail and not gone for good).
BTW - there are a couple of other bugs that I encountered with emClient, which make my move back to Outlook a bit easier:
Updating calendar invites in emClient - did you ever notice that when you update an invite directly in emClient’s calendar, it asks you if it should send an update to all attendees - well, even if you click “yes” - they never get the update …
… my workaround was that I had a separate Google Calendar browser window open, where I made changes, as the Google Calendar follows through on sending updates to attendees.
I had constant errors when I synced my Gmail address book since my university also shares the full directory, which is quite huge (25k+ entries). Apparently, the way emClient syncs address cards puts a load on the server, where the server then refuses the connection: “Temporary problem - please try again later and consider using batch operations. The user is over quota.” - I don’t have seen this issue with any of my Android or other PC applications such as Mailbird.
I hope it works out for the others who had the issue with permanently deleted e-mails. For me, the way they blame it on a server without re-thinking the way they fetch messages is just the straw that breaks me and makes me cut my losses - yes, I’ve paid for the PRO version, but it’s not fully pro ready.
Thanks for the update Georg. The interesting this is that even when I tried your method to trigger the bug, I cannot do it with my server. So this clearly is a server issue that may be specific to the way eM Client accesses it. Of course it seems that Google is particularly troublesome, especially with eM Client. Other email clients like Thunderbird and MS Outlook, have different ways of communicating with the server, so where a server bug shows up on one, it may not on another.
Have fun with MS Outlook. I will miss your stimulating comments.
As a developer I have written fire and forget code many times. I don’t always like it and caution clients about it. However, fire and forget here, that is to say “do something without a return code” is very dangerous in this situation. emClient is doing something based upon an assumption that the host is taking care of something. It is therefore losing the local copy and trusting the server will do the right thing. This isn’t great practice. Also, pointing a finger at the back end saying it’s a server (IMAP) problem isn’t helpful as the IMAP spec is about as slow to change as laws in congress. So, what can be done? Loss mitigation. Give me a “can undo delete” checkbox for the account. If I override it, CTRL+Z does nothing but pop a message or silently fails. This way, the message moves into deleted and I can go get it there vs helplessly watching it reappear then be gone forever.
Adding this video back to the mix: https://www.dropbox.com/s/dvuoutwsn1zpj3e/4DB504D8-DC0B-4203-83B8-10B9ADB21E40.avi?dl=0 This happened to me today. I deleted something from a gmail account. Quickly CTRL+Z undid it. It flashed and was gone completely. I would LOVE if I could just turn off the undo delete function! As you can see in my video it works on an exchange account (the first test) but the second bubble shows CTRL+Z brings it back for one second, then its gone forever. How can we get this fixed or at least mitigated?
I have the same issue. When I go through and delete a ton of email from my inbox, sometimes the emClient falls behind. When it catches up, it deletes a few too many messages so I try CTRL+Z and now they’re gone forever. I go in to my Gmail web client and it’s not there either. Problem is it happens so fast, I don’t even know what message it deleted to try and get back with the sender and resend. Ugh. Might have to look for another alternative client as I’ve lost at least a half a dozen emails (that I know of) and have no idea what they were about.
