GNOME Bugzilla – Bug 714728
Make attachments pretend to live in /tmp
Last modified: 2017-12-11 07:13:38 UTC
---- Reported by rschroll@gmail.com 2013-04-09 21:57:00 -0700 ---- Original Redmine bug id: 6791 Original URL: http://redmine.yorba.org/issues/6791 Searchable id: yorba-bug-6791 Original author: Robert Schroll Original description: Geary stores attachments in a directory structure like `~/.local/share/geary/<email>/<foo>/<bar>/`. When the user opens the attachment, this file is opened directly. This bothers me, for a few reasons: 1) It tempts the user to modify the file in place. This can only end badly, whether Geary will revert these modifications or not. 2) It may take some extra effort to navigate back to your home directory, whether by moving parent directory to parent directory or by finding the right level of the path to click on. Granted, this is a fraction of a second delay, but these kinds of things cause irritation, often at a sub-conscious level. 3) When you do get to your home directory, it may be showing hidden files (since you had been in a hidden directory). Now you have to waste a few more fractions of a second hiding the hidden files again, so you can see what's going on. When I open an attachment, I expect to be getting a temporary file, and therefore I expect it to live in /tmp. Finding it elsewhere if just slightly surprising, and surprise is bad for UIs. Making the file appear to be in /tmp (or a subdirectly thereof) would solve the above problems. I see two ways to do this off-hand: 1) Copy the file to /tmp before opening it. 2) Make a symlink in /tmp to the file. The latter would make it easier to avoid creating duplicates, but it wouldn't by itself protect the original from modifications. Related issues: related to geary - Feature #6086: Optional downloading of attachments (Open) ---- Additional Comments From geary-maint@gnome.bugs 2013-11-14 17:13:00 -0800 ---- ### History #### #1 Updated by Charles Lindsay 8 months ago * **Target version** set to _0.5.0_ That sounds reasonable to me. As far as I'm concerned we shouldn't be automatically saving attachments anywhere (see #6086), so /tmp seems like as reasonable a place as any to store them when launching. #### #2 Updated by Jim Nelson 7 days ago * **Target version** deleted (<strike>_0.5.0_</strike>) --- Bug imported by chaz@yorba.org 2013-11-21 23:11 UTC --- This bug was previously known as _bug_ 6791 at http://redmine.yorba.org/show_bug.cgi?id=6791 Unknown version " in product geary. Setting version to "!unspecified". Unknown milestone "unknown in product geary. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution
This is strictly related to bug #714094. I think we should first implement the optional downloading and then think where to store the downloaded files. In the discussion in #714094 (comment 1) it was suggested to store downloaded files for a limited amount of time (1or 2 weeks). If we store them in /tmp they will last only until the end of the session. I see in ~/.cache/geary that something is stored there (e.g. avatars). It might be a good place.
I'm going to resolve this as won't fix since we want to be writing less things to /tmp, not more: Saving files to /tmp lik ethis won't work under Flatpak in a strict sandbox - See Bug 779311 and https://github.com/flatpak/flatpak/issues/592 for more info. When Bug 714094 gets fixed, the process for opening or saving an attachment will work much like downloading a file in Epiphany: Opening will save it to the XDG downloads directory and open it from there, saving it will prompt for a location to save it, defaulting to the last used directory or XDG downloads. No /tmp needed.