If an email attachment is viewed by "Open Directly", it's stored to /tmp as e. g. trojita-attachment-GbKZiL-IMG_1553709514157_94340.jpg or such, and a connected program is started to vew the file. The problem however is that the temporary file is deleted after ca. 10 seconds. If I open an image file, it's viewed by gwenview, but after 10 seconds, it's gone, gwenview doesn't show anything anymore and also, the file in /tmp is gone. Same result for a .txt file viewed by kwrite, in this case, only a notice shows up that the file has been deleted by another program. So I think trojita cleans up those temporary fles when it shouldn't.
This is caused by the way QTemporaryFile is used in Gui/AttachmentView.cpp. In openDownloadedAttachment(), just after the QDesktopServices::openUrl() call, m_tmpFile is deleted. From the Qt docs: The name of the temporary file is guaranteed to be unique (i.e., you are guaranteed to not overwrite an existing file), and the file will subsequently be removed upon destruction of the QTemporaryFile object. Here we are ... I don't think this is desired behavior: Either, one should keep the file object until trojita is closed, or not use QTemporaryFile at all in this case, and e. g. do a cleanup of old temporary files on the next startup. Well, if you want to change this, one has to do a decision on how to implement it, as this is no bug in the code but caused by the implementation itself ...
https://bugs.kde.org/show_bug.cgi?id=344606
Well okay, using the git master code, this problem doesn't show up anymore (Which is a bit surprising, I looked at the git master sources, not the 0.7 ones, which remarkably differ a lot, and was pretty sure it was caused by the deletion of m_tmpFile ... but however). Maybe after 385 commits, you want to tag a new release soonish? I mean, the 0.7 tag dates back to 2016 ;-)