/tmp does not belong in file save dialogs.

Here’s something that shouldn’t happen.

  • User reads her email with a web-based email service, using Firefox.
  • User opens an MS Word document (something.doc) that someone sent her via email. OpenOffice opens it.
  • User changes document and saves it with a new filename (something_changed.doc). OpenOffice offers to save it next to the existing document, which Firefox put in /tmp, because Firefox thinks it’s just saving a temporary copy so it can tell OpenOffice to view it. User says OK, because what does the User know about “tmp”?
  • User shuts the computer down.
  • User starts the computer.
  • User tries to find the document. After much difficulty, she finds /tmp, but the document has been deleted (because it’s deleted at startup, though the user doesn’t know this).

This happens in Ubuntu Dapper and Edgy at least. I think that Firefox in Ubuntu Breezy used to save the temporary documents to the Desktop, instead of /tmp, which was also annoying.

I’m not sure what the best general solution is, but I can imagine that some of these might help:

  • Temporary documents could be read-only.
  • GtkFileChooser could warn about saving documents in /tmp, and/or not allow /tmp to be shown when saving documents.

40 thoughts on “/tmp does not belong in file save dialogs.

  1. I’ve come across this problem before. More than once I’ve seen non-technical (but not exactly inexperienced) users lose essays on Ubuntu this way, the day before the submission deadline, and have to rewrite them from scratch. It is a bug, and a very serious one.

    Back when I saw the essay loss was before I knew how to use Ubuntu’s bug system. Is there a bug somewhere about this? There should be.

    At the time I had much difficulty deciding which application was to blame and needed to be fixed — Firefox or OpenOffice. Your suggestion of putting the fix in GtkFileChooser seems like the right one to me.

    I think this is worth a bug report and should be high priority, it’s a usability bug that can cause data loss.

  2. This is a problem on Windows, too, so GNOME users are certainly not alone here. Opening documents from Outlook or Internet Explorer used to be a fast track to losing them as soon as the window was closed, because they were saved in a hidden folder that was protected by a shell extension from in-depth viewing – in other words, virtually impossible to find from anywhere but the command line. Newer versions of Outlook now check for changes to the document and give you an option to save it somewhere useful (like back into the original e-mail).

    Knowing where to find the lost documents is a good way to net yourself big brownie points with hyperventilating undergraduates.

  3. I save temporary files in /tmp, so you know at least one person which would be very annoyed if you disallow /tmp.

    A solution would be to make a special “Temporary” location, which would really be /tmp, but would at least make things clear for a newcomer.

  4. /tmp is probably the most frequent location that I am using the Save file-chooser for. Would be rather annoying if that wouldn’t work any longer.

    The real problem to address here is not the file-chooser offering to save in /tmp but the fact that the document is opened from /tmp. Firefox should somehow pass the document to the viewer application without associating a location on disk. It should probably pass the filename to be used as the default when saving. And of course it needs to pass the data somehow and I don’t really care if it uses the /tmp folder for that. The opened document however should appear as unsaved and must not have a disk location associated with it.

  5. The same problem happens if you open some pdf from your browser to evince and you quit session, when you come back and the session restores evince it will show empty because the document no longer exists (was deleted from /tmp on reboot). So the user is confused why sometimes the session restores evince with its last opened document and sometimes not. The user does not know that opened pdfs from Internet will be deleted on next reboot though he leaves Evince opened with it when quitting session.

    See a mail about that I sent to evince-list:
    http://mail.gnome.org/archives/evince-list/2005-October/msg00004.html

  6. The real solution to this problem in my opinion is to make sure that /tmp is never the default when SAVING a document, even if it was opened from /tmp.

    What I consider the Correct Use case:
    1. User clicks on link to document in Firefox and asks to OPEN the file rather than SAVE.
    2a. User reads document and clicks “CLOSE”. Application asks if the user wants to save a copy of the document on the hard drive before exiting and warns that the file will be lost if not.
    or
    2b. User starts editing document and choses “SAVE”.

    3. No matter if 2a or 2b, File Save dialog opens with a default path of ~/Documents/filename rather than /tmp/filename. Swap Documents for Pictures/Music whatever if applicable.

  7. Another case where this is an issue:
    1. Take a screenshot
    2. Drag the screenshot preview directly from the screneshot dialog into the Gimp
    3. File->Save
    4. Be confused as you see the current directory in the save dialog is something like /tmp/gnome-panel-screenshot-724521734

  8. Hi Murray,

    I am using Debian SID and browsing my corporate mail from firefox. When downloading/opening documents from mail, OpenOffice start in read-only mode.
    Is a good feature. You have to save-as previous to editing…

  9. > /tmp is probably the most frequent location that I am using the Save file-chooser for.

    How is this anything but a bad idea? You’ll lose the data.

    Maybe the problem is that you often have to save temporary copies of things just so you can open them. I suspect that’s the fault of one or two particular programs that you use. Just guessing.

  10. Actually, just this thing happened for my girlfriend today on Windows.
    IMO Evolution gets this quite right – write protect the file, to prevent the user from saving it in a temporary folder without consent. The default folder to save to should however be standardized!!!

  11. Absolutely. My sister uses her email account as a hacky network filesystem, and until she got bitten badly, she’d just click her webmail links to her openoffice documents and let them open in on OOo. Of course firefox puts the file in /tmp for this case. She spent some time working on a paper and forgot to email the file to herself before shutting down. 2-3 hours of work gone.

    Something like GNOME Storage is a cool idea. By default, documents could get put in a generic store/temp area where they’re always going to be available until you clean it yourself. Of course this isn’t terribly different from simply putting everything on the desktop by default at every chance.

  12. Agreed, a warning would be nice!

    The file save dialog should also warn me when I’m on a directory, with no subdirectories, and I don’t have write permissions. It’d be nice to realize saving is going to fail before pressing the button :)

  13. Sure, I will lose the data, that’s why I put things in /tmp. How often do you actually download anything that you will need later?

    The other use case for putting things in /tmp is testing software and that’s probably the main use case for me. Sure, I am not a common user, not at all. But you should nevertheless try not to make the desktop too hard to use for the developers that are building it.

  14. >> /tmp is probably the most frequent location that I am using the Save file-chooser for.

    >How is this anything but a bad idea? You’ll lose the data.

    I also save most of my files to /tmp. For example, save a jpg file from firefox, then open it with gimp to upload it to fotolog.net – I don’t want to keep the file on my disk

    Saving to tmp should not be forbidden, a warning is more than enought

  15. > a warning is more than enought

    The problem is that users ignore warnings, understandably. However, if we avoid showing /tmp by defaul then they won’t even see the warning.

  16. Most of the resistance here is of the form “I save things to /tmp now, and you can’t remove that feature”.

    But an OS shouldn’t simply be a superset of all features found on all previous systems. (Otherwise my dad would insist it have a panel of switches for toggling in machine code. Yes, really.) It’s OK, and in fact good, to get rid of bad features and old ways of doing things, even if it means some people have to change their ways. (You’ll live.)

    I used to use Lynx and press ‘d’ to download. Now I right-click, Save as. Is this bad? No. Different way to accomplish something, same result.

    Similarly, I don’t see the harm in disallowing /tmp; it just means that if you want something there, you’ll have to move it there. Considering the tradeoff is “normal people losing their data without knowing it” versus “some Linux junkies commenting on a blog will need 2 steps instead of 1 to put something in a place that has magic features”, I think that’s a bargain.

  17. I like my browser using the desktop as temporary download folder.
    It’s the desktop after all, a workspace for non-permanent storage.

  18. I suggest that /tmp is only used as a virtual place – so “save temporary” – and let GNOME decide what is temporary. Maybe this is $HOME/tmp then.

  19. Nice catch! I didn’t know /tmp was automatically cleaned on startup, that sounds quite destructive to me. Of course, this is not just any personal temp folder, it’s the UNIX /tmp folder so I’m not surprised.

    The best solution would be for GtkFileChooser to default to ~ (or even better, ~/Documents, but that’s for Topaz!) whenever a file is opened from /tmp. Making it read-only would just be annoying.

  20. > The best solution would be for GtkFileChooser to default to ~ (or even better, ~/Documents, but that’s for Topaz!) whenever a file is opened > from /tmp. Making it read-only would just be annoying

    Then you’d still lose data when doing a regular save instead of a save-as. And anyway, the GtkFileChooser wouldn’t know where the original document was saved. If we have to fix every application individually then we’ll never fix this.

  21. Isn’t this exactly what the Desktop VFS ideas are all about? If there was a DocumentSave() api call, then this kind of interaction could be handled well. Otherwise, any app that just calls write/fwrite or some equivalent would have the Save vs Save As issue. Wrapping the low level api with some higher level function like this would allow the desired behavior. If someone truly wants to save to /tmp then a warning could be displayed (along with a ‘don’t show again’ checkbox) and both types of user are happy. Neither the problem, nor the solution seems to be in GtkFileChooser, but in the open/close/read/save functions.

  22. Use a sane operating system or Linux distribution and this is a non-issue.

    Having /tmp be a ram drive (like on Solaris) is a bad idea for many reasons including the fact that contents won’t survive a reboot.

    Having a /tmp be cleared on boot is a bad idea.

    On Fedora, and derivatives, files in /tmp are deleted automaticaly once they haven’t been accessed or viewed (atime) in 10 days. This is very elegant. On my Fedora box this is where I download files by default. If something is a “keeper” then I know to move it to a permanent location (and I have 10 days to do so).

    Please don’t implement some hack in GTK just because your operating system or distribution uses non-sane /tmp handling.

    1. /tmp is specd by the FHS as ‘might be cleared between boots’ –
      http://www.pathname.com/fhs/2.2/fhs-3.15.html
      – so your personal opinion or jabs at particular OS versions really don’t matter. DEs should nonetheless treat this ‘might’ as a reason to check whether users are sure (via a warning and a preference option to disable this) to avoid naïve users losing valuable work and pestering developers.

      Anyway, your example of Fedora now mounts /tmp as a tmpfs by default –
      http://fedoraproject.org/wiki/Features/tmp-on-tmpfs
      – so, heh. so much for that “sane” distribution now, I guess!

      I like this behaviour for reasons including lightning-fast compilation in a RAM drive and the fact that I can discipline myself to save in the right place or suffer the consequences, so I added it to my Debian box. Rumour has it this will be default in the next-stable too.

      Anyhow, if this read-only thing is still extant, I’ll pester them about that later on Bugzilla, something I apparently can’t get enough of.

  23. The common use of /tmp seems completely whacked, to me, anyway.

    If I browse to http://www.some-secret-site.com, and want to view secret-document-49152.pdf, it dumps it into /tmp. Sure, it’s probably not world-readable, but anybody can see that I’m looking at “secret-document-49152.pdf”. If it’s not a password-protected file and has a reasonably unique name, you can just google it, and find what I’m looking at.

    And if you have more than one user with a web browser, /tmp gets a million files in it.

    Why don’t distributions create a ~/Temporary/ folder for each user? Then you could even provide the option of specifying your own temp-file strategy: “Delete untouched files after 10 days” (default), “Delete all on reboot”, “Delete old files when over 250 MB used”, “Never touch”, etc. On second thought, I’m not sure that such a preference is a good idea, but it’d be possible.

  24. I got an Ubuntu liveCd, and I was trying it out. Using liveCD, tmp is one place files can written to, by default. This use would need to be considered.

    Warning users that files can be deleted if saved in that location is good, as is having a default preference for suggesting a good location. Preventing the use of tmp would be not good.

  25. > On Fedora, and derivatives, files in /tmp are deleted automaticaly once they haven’t been accessed or viewed (atime) in 10 days.

    Deleting after 10 days is not much better than deleting after a reboot. I shouldn’t lose my data.

  26. > Neither the problem, nor the solution seems to be in GtkFileChooser, but in the open/close/read/save functions.

    Yes, it would be nice to abstract some of that code into a library, and there’s discussion on gtk-devel-list about that now. However, if we have to patch every application individually to make it use this new API (which in this case would also require a change of architecture) then the problem will never be fixed generally.

  27. I second Snark. Don’t take away my ability to save to /tmp .

    >> /tmp is probably the most frequent location that I am using the Save file-chooser for.

    >How is this anything but a bad idea? You’ll lose the data.

    Maybe I don’t want to save the data?

    >Why don’t distributions create a ~/Temporary/ folder for each user?
    Is a bad idea for multi-user systems, as it will require more disk space, and could slow down reboots (imagine checking 1000 user’s home for a ~/Temporary and then deleting files).

    A better idea would be to use a directory under /tmp that is read-only for that user, that would provide privacy for the user and make it easier/faster to delete stuff.

    >Warning users that files can be deleted if saved in that location is good, as is having a default preference for suggesting a good location. Preventing the use of tmp would be not good.

    I agree with that Crf.

    It tough trying to make a GUI that is good for newbies, but is still good for technical folk. For instance if I got a warning every single time I saved to /tmp I would be annoyed. I like to save stuff to /tmp that way I don’t have to remember to delete it when I’m done.

  28. >> /tmp is probably the most frequent location that I am using the Save file-chooser for.
    > How is this anything but a bad idea? You’ll lose the data.

    I frequently manipulate various temporary stuff. /tmp is the perfect location for them, as it’ll get cleaned up on the next reboot, so I don’t have to remember to do it. And don’t reboot more often than every 2 weeks, so there’s little chance I leave anything there I could miss later.

    > Maybe the problem is that you often have to save temporary copies of things just so you can open them. I suspect that’s the fault of one or two particular programs that you use. Just guessing.

    Not anyone’s fault, just workflow. I quite frequently end my GIMPing with .xcf to a permanent folder, and distribution format (png / jpg) to /tmp for uploading. Don’t disallow /tmp, or I’ll have to hate you. Changing its display name to “Temporary”, fair warning (but no popups please) are all good ideas, but /tmp is a perfectly valid save location and trying to “protect” users from it is going to be as annoying as Clippy.

  29. > Then you’d still lose data when doing a regular save instead of a save-as. And anyway, the GtkFileChooser wouldn’t know where the original document was saved. If we have to fix every application individually then we’ll never fix this.

    Ah, that’s an issue, yes. Maybe it would be sufficient if all “Gnome” apps were updated with this, and most specifically, OpenOffice.org, gedit. What do you mean with the latter part, doesn’t GtkFileChooser suggest the last saved file name (at least if the app tells it to)?

  30. It’s not a sole ubuntu/linux/gnome problem, as exactly this happened to my girl friend 3 days ago. She’s used to open all her documents from a firefox bookmark or from within a mail (using thunderbird). Recently I send her a reviewed version of her thesis and she started to do changes to the document, saved and closed it. Next time she opened the document she wondered, why all the changes vanished.
    This was using OO.org under Windows. Happily for her, I remembered, where all the temporary files are stored and was able to restore her changes.

    Lesson: Firefox and Thunderbird should save temporary files (even for viewing) in a more save location and warn the user about changes to it. Making the temporary file read-only would force the user to choose a new location and name.

    Nikolaus

  31. Please how do I recover these files? They don’t seem to be in the trash (where you would expect them) so where the heck are they and what do I need to do on my computer to recover them.

  32. I was e-mailed a set of files. I saved all but the key one to my desktop.
    I did not notice the main one was opened / saved to /tmp. Not trusting editors
    I hit ctrl S on a regular basis. 8 hrs later, I hit a final ctrl S and exit, so I can e-mail
    the final version. It’s gone. I worked in IT since the 70s. (Unix,VMS, Windows etc).
    If I can do this … well I dont think this is a good idea.
    Why would I hit ctrl S if I wanted the result to be lost ?

  33. To Mick T. and Mark, the “defenders of the ability to save to TMP” … I have a question for you guys: ARE YOU CRAZY?

    TEMP DIRS are for the APPLICATIONS and the OS internal use, never to save files to. Where did you guys acquire this unhealthy -no to say stupid- behaviour??.

    I have a dir…. “WORK” or “INCOMING”. I dump all my downloads on either one. I repeat: there’s absolutely no reason for which users should save stuff from a browser to /tmp.

    If you want to continue your stupid behaviour fine, but don’t impose your whicked views on the rest of the users. The majority of commenters here are right: this is a bug and should be dealt with. I couldn’t care less about two people “affected” because they liked to save files from the browser to tmp (or /var/www/error for that matter!!).

    Just my $0.02
    FC

  34. In TEN YEARS I still am being besieged by GIMP, being launched by Spectacle (KDE screenshotter that’s quicker than telling GIMP to use its own internal screenshotter) TRYING TO SAVE FILES IN /tmp BECAUSE THATS WHERE spectacle PUTS THEM!

    What will it take for this problem to be gone for good…

Comments are closed.