Bug 827581

Summary:	Firefox saves temporary downloads to /tmp
Product:	[Fedora] Fedora	Reporter:	Nicholas Miell <nmiell>
Component:	firefox	Assignee:	Martin Stransky <stransky>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	cbm, gecko-bugs-nobody, lpoetter, mganisin, opensource, samuel-rhbugs, stransky
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-10-30 14:38:22 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	826015

Description Nicholas Miell 2012-06-01 19:22:02 UTC

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 11:46:36 UTC

So what do you suggest here?

Comment 2 Nicholas Miell 2012-06-07 19:50:30 UTC

I don't have a suggestion, this is just here so it can block bug 826015.

Comment 3 Lennart Poettering 2012-06-20 10:49:17 UTC

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 19:24:44 UTC

(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 18:44:31 UTC

(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 09:21:42 UTC

(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 21:20:43 UTC

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 22:27:51 UTC

Firefox cleans up after itself already.

Comment 9 Marian Ganisin 2012-09-13 06:31:53 UTC

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 14:38:22 UTC


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