Bug 827581 - Firefox saves temporary downloads to /tmp
Firefox saves temporary downloads to /tmp
Status: CLOSED DUPLICATE of bug 860814
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Martin Stransky
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F18TmpOnTmpfs
  Show dependency treegraph
 
Reported: 2012-06-01 15:22 EDT by Nicholas Miell
Modified: 2012-10-30 10:38 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-30 10:38:22 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nicholas Miell 2012-06-01 15:22:02 EDT
When you download a file from a web site and choose the Open With Application option, Firefox saves the file to /tmp and keeps it around until you quit the browser.

This is problematic when /tmp is a tmpfs if e.g. the user downloads a large movie and chooses to watch it in Totem or a DVD image and choses to open it with Brasero.

It would also be problematic with long lived browser sessions where the user downloads and views many smaller files.
Comment 1 Martin Stransky 2012-06-07 07:46:36 EDT
So what do you suggest here?
Comment 2 Nicholas Miell 2012-06-07 15:50:30 EDT
I don't have a suggestion, this is just here so it can block bug 826015.
Comment 3 Lennart Poettering 2012-06-20 06:49:17 EDT
Here's an explanation of the siuation:

http://0pointer.de/blog/projects/tmp.html

Based on the description in this bug this really appears to be something that should be in $XDG_CACHE_HOME. See http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html for details.
Comment 4 Till Maas 2012-07-13 15:24:44 EDT
(In reply to comment #3)

> Based on the description in this bug this really appears to be something
> that should be in $XDG_CACHE_HOME. See
> http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html for
> details.

What is supposed to make sure that old files are removed from there?
Comment 5 Lennart Poettering 2012-07-20 14:44:31 EDT
(In reply to comment #4)
> (In reply to comment #3)
> 
> > Based on the description in this bug this really appears to be something
> > that should be in $XDG_CACHE_HOME. See
> > http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html for
> > details.
> 
> What is supposed to make sure that old files are removed from there?

Nothing. Note that /tmp is not guaranteed to be cleaned up either. It is by default on Fedora, but it isn't for example on Debian. Hence either way upstream code shouldn't rely on external automatic clean-up.
Comment 6 Till Maas 2012-07-21 05:21:42 EDT
(In reply to comment #5)

> Nothing. Note that /tmp is not guaranteed to be cleaned up either. It is by
> default on Fedora, but it isn't for example on Debian. Hence either way
> upstream code shouldn't rely on external automatic clean-up.

But it is also not guaranteed for a upstream program to run regularly, therefore it cannot always clean up. For example I once started evolution by accident and now there is ~/.cache/evolution that is never going to be deleted as far as I can tell. And for /tmp it is at least recommended by the FHS to clean it up when the system is booted.
Comment 7 Lennart Poettering 2012-08-03 17:20:43 EDT
So, gnome-settings-daemons actually does have a "housekeeping" plugin that will clean things up in the cache. If this is really an issue it can be trivially extended to clean up firefox' temporary downlodas (or in fact all of XDG cache).
Comment 8 Nicholas Miell 2012-08-03 18:27:51 EDT
Firefox cleans up after itself already.
Comment 9 Marian Ganisin 2012-09-13 02:31:53 EDT
This bug seems to have wrong component assigned. /tmp is system service. If it isn't able to fulfil requirements of users and/or applications then it is issue of os/distribution.
Comment 10 Martin Stransky 2012-10-30 10:38:22 EDT

*** This bug has been marked as a duplicate of bug 860814 ***

Note You need to log in before you can comment on or make changes to this bug.