I’ve previously written about how I recovered an unsaved document over the dbus service from the GNOME Text Editor (GEdit) after the desktop shell session had crashed. Here’s a similar and exciting tale from the exciting world of desktop email applications!
Evolution, the GNOME ’desktop project’s email and personal information management client, has a bad data loss bug. It sometimes deletes the email body text in the compose window after changing the signature using the signature presets menu from the. I don’t know the exact steps to reproduce it but it has bitten me about twice a month for the last two years. The contents of the email is simply deleted and you’re left with an empty message except for the new signature.
To make matters worse, the Undo history is cleared so I can’t press Ctrl Z to restore the draft. I’ve learned to avoid it by changing the signature before I start to write a reply. Sometimes I forget and then it’s data loss bingo-time! Either I’ll lose the email or it’ll function properly. I’ve never lost more than a paragraph or two.
A few days ago I lost a long email that had taken me half an hour to compose. I remained completely calm and didn’t walk away from my computer in frustration. (Not.) I might have been able to partially recover the message from the Draft folder if I’d retained my cool and acted immediately. It had been overwritten by an empty message instead. I must look into versioning my email draft folder at a later time.
All hope wasn’t lost, however. To quote a beloved paleontology fantasy film: “It’s a Unix-system! I know this! It has all the files for the whole park. It tells you everything! I’ve gotta find the right file. ”
This time around, I hadn’t closed Evolution or the compose window after the bug revealed its ugly face. A complete copy of my email could remain in memory. My computer has 2019 GB of RAM and going through all of it blindly is both technically challenging and time-consuming.
Linux maintains a map of a process’ memory allocations in / proc / $ pid / maps , where $ pid is the process identifier / number of the running process. There are multiple tools available for retrieving the chunks of memory corresponding to these addresses and saving them to a regular file.
I settled on a combination of pidof (installed as part of procps-ng ) for identifying the process number, and gcore (installed as part of gdb , the GNU Debugging Toolsuite) for reading the process’ memory to a file. Here’s the final command I used:
This produced a huge 4 GB binary memory dump file. Comments about how memory hungry modern desktop applications are aside; This is still a lot of data to go through. There are specialized tools you can use to analyze this data blob. However, I settled on using the nano text editor. It’s “comfortable” working with massive files and doesn’t choke when you use it to read reading binary data. I knew that the data I was interested in would be stored in UTF-8 so a text editor should be able to recognize it.
Searching through this huge file took a long while. There’s just a lot of data to churn through. I initially thought that searching for unique words would be the best approach. The first dozen matches I found were data related to the spell-checker. However, I changed my mind and search for partial sentence fragments I could remember instead. This new approach would miss out on any quoted-printable (RFC 2045) representation of the message but would give a fewer fragmented matches.
Using this method, I was able to identify and retrieve a plain text copy of the complete email. The copy I retrieved from RAM notably had the new signature I’d selected when the email contents disappeared from the editing window.
I’m glad I managed to recover the email this time. However, I should probably set aside some time to migrate to another email client. Evolution is great! I’ve run into multiple issues with the email composer window in particular. An email client isn’t really useful when I can’t reliably use it to write emails.
GIPHY App Key not set. Please check settings