GNOME Bugzilla – Bug 673097
Do not allow saving attachments into the hidden temporary cache folder
Last modified: 2013-07-30 11:02:14 UTC
Created attachment 210877 [details] screenshot When opening an attachment, evolution creates a subfolder in ~/.cache/evolution/tmp/evolution-[username]-[randomhash], and puts the file there. However, here's what happens with the average non-geek user who doesn't pay a *lot* of attention to what's going on with the GTK filechooser: from the application that opened that temporary attachment file (let's say, LibreOffice or Gedit or eog), if the user tries to save the file (or to use save as), it will default to saving to that hidden temporary folder. And then the user can't find the file anymore and complains that the system is badly designed. So far my initial thoughts on how to work around this would be to do this initially: - create tmp/evolution-[user]-[hash]/ and write the attachment file into it - chmod -R ug-w tmp/evolution-[user]-[hash]/ (make it read-only) This would depend on fixing the GTK filechooser bug 601451. Or do you have another solution in mind?
Ah and it also means that when you shutdown/want to cleanup the tmp files, you have to chmod them again to re-add write permissions before trying to delete the directories.
Thanks for a bug report. I understand your point, it happens to me too, from time to time. What I do, to find my "lost on a disk" file, is to open the other application and check list of Recently opened files. Playing with read-only attribute is doable, but it will break eventually, because of threading - when multiple threads will try to add a file, then one thread can "lock" (set read-only) the folder before another thread opens its file and writes the content into it, causing failure of the file save. The right approach would be to fix all the other applications (I know, it's technically undoable), to not allow save into hidden folders (basically into ~/.cache, or the one as defined by XDG).