Description of problem: I'm not sure this belongs here, anyway somewhere I'll like to report. The story is this. Sometimes, browsing the web, PDF documents are opened by firefox using an external viewer (and not by the internal viewer), which usually is "evince", which I suppose is called by "gvfs-open" or "xdg-open". If I store the document on an external, detachable, storage (USB, or the like), for some reasons a copy is made available in /var/tmp, visible in "Recent" folder of Nautilus. Actually, my suspect is that the request of the "Recent" folder makes a copy into /var/tmp, not sure about the cause-effect relationship. Nevertheless, sometimes these documents are bank reports, which should be stored in an encrypted drive and they should *not* be available anywhere else in the filesystem. I would expect them to be stored in /tmp or, better, in $TMPDIR. This is because I've /tmp as tmpfs already (as planned by F19, I guess) and so the storage is anyway non persistent. Even if, the permissions of the document should be "private" anyway. So, I think it is a "bug" the usage of /var/tmp as temporary storage in this situation, hence this report. Version-Release number of selected component (if applicable): gvfs-1.14.2-4.fc18.x86_64 How reproducible: It seems always Steps to Reproduce: 1. Open, with FF, a document, from web page, by external viewer 2. Store it, from the viewer, into a removable folder 3. Request "Recent" folder access from nautilus Actual results: There is a copy of the document in /var/tmp Expected results: No copy should be made, at least not in /var/tmp Additional info: This report might be a bit confusing, in case it results difficult to reproduce the issue, I can try to provide a systematic protocol.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Update to F-20. bye, pg
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Keepalive bump to F22. To be honest, I did not check if this is still valid, since I'm using a workaround. I'll check and, possibly, close the report. bye, pg
I don't see such behavior currently and also I don't think so it was caused by the gvfs. I suppose it is duplicate of Firefox Bug 1161110, because downloaded files were in /var/tmp before... *** This bug has been marked as a duplicate of bug 1161110 ***
It's the second side of the problem. Firefox always starts downloading _immediately_ in the background, putting a temporary file into /var/tmp, while waiting for the user to answer the dialog where to save things. That has been explained either somewhere in the ticket dependencies or in the related devel@ discussion(s). Bug 1161110 was about not evaluating $TMPDIR and overriding it always. The fix/woraround for it didn't change Firefox's behaviour of using /var/tmp at the start of downloads.
Bug 867073 was about hardcoding /var/tmp in /usr/bin/firefox.