Users should be discouraged from editing temporary files

I think the simplest way to address this would be for temporary files to be set
read-only by default. This would prevent the user from saving their changes
back to the same file.

I don't want to change this for breezy, because I have a feeling it might break
something.

both mdz and ijackson confirmed this.

This is a very common problem, I have seen tens of persons saving to /tmp/.

I think it should be fixed in OpenOffice.org save as dialog. When the "File: Save as" dialog is shown:
1) Check if "Save in folder" is /tmp/ or /var/tmp/
2) If yes, change the "Save in folder" to $HOME
In Evince pdf document viewer, it is already solved like this.

In the highly unlikely (imposible?) case that user wants to store a document under /tmp, he is free to navigate to that directory.

It is most important to correct this in OpenOffice - more than 95% saves in /tmp/ I have seen are done with OpenOffice. After that, abiword could use a similar fix. For other programs I use cfengine to create warning files to temporary directories:
/tmp/_DONT_SAVE_DOCUMENTS_HERE_they_will_be_automatically_deleted
/var/tmp/_DONT_SAVE_DOCUMENTS_HERE_they_will_be_automatically_deleted

I have come across this issue also, I've seen people lose essays on Ubuntu this way and have to start them again. In fact, this is a very serious usability issue because:

1. It can result in data loss, including complete loss of important data, such as an entire essay.

2. Most users will fall into this trap, they don't notice the file is being saved in /tmp, they don't know that /tmp will be wiped when they restart their machine. I've seen experienced users loss documents because of this.

I suggest we raise the importance of this bug.

Also, see this blog post from Murray http://www.murrayc.com/blog/permalink/2006/10/31/tmp-does-not-belong-in-file-save-dialogs/ in which he recommends fixing the issue in GtkFileChooser:

"GtkFileChooser could warn about saving documents in /tmp, and/or not allow /tmp to be shown when saving documents."

P.S. I don't know how to do this, but I think this bug report should be linked to GtkFileChooser as well as or instead of Firefox, as I think the file chooser is where the correct fix resides.

I commented the following to the blog post :
<<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. >>

I think Tero Karvinen's solution of patching gtkFileChooser is excellent:

[quote]
When the "File: Save as" dialog is shown:
1) Check if "Save in folder" is /tmp/ or /var/tmp/
2) If yes, change the "Save in folder" to $HOME
In Evince pdf document viewer, it is already solved like this.

In the highly unlikely (imposible?) case that user wants to store a document under /tmp, he is free to navigate to that directory
[/quote]

If it is found to be objectionable that people using /tmp as working directory have to browse to /tmp every time they save their file: a solution with read-only flag for temporary files can be thought of (gtk-file-chooser will only do /tmp-->$HOME when file is read-only) but this will require patches for all pieces of software creating the file in /tmp.

hi ubuntu community

the idea of karvinen is the BEST. Not great, not excellent, not good IT'S THE BEST EVER! Just implement it and don't discuss it.

It would be good if there is a warning when you select /tmp right in the save panel, not a popup after pressing save or redirecting the file.

For some reason the documents saved from the web in Firefox for instance are saved with a 600 permission while when saved from Open Office they get 644 permission. Personally, that just lost half a day of work, I will install a filter copying all files in /tmp with my user and 644 permission to $HOME/tmp just before /tmp is cleaned up on boot. I just have to find the place where it is done first....

OK, this works for me: I just changed the /etc/init.d/bootclean

joakim@alcatraz:/etc/init.d$ diff bootclean.sh bootclean.sh~
63c63
< ! -perm 644 ! -type d -print0 | xargs -0r rm -f
---
> ! -type d -print0 | xargs -0r rm -f

to not remove any files with 644 permissions. This allows me to detect my error saving stuff in /tmp In the end this may cause /tmp overload so Ubuntu developers might want to add a policy to copy teh files to each users garbagecan and popup an alert that some suspisiosly looking files were put there, or something.

Changed to sysvinit since the root cause is not application (ie Firefox) specific

How would the change in sysvinit discourage people from editing temporary files?

Well, it is simple change to 'allow' people to do this without loosing their work and the discouragement lies in the extra effort to pick the file up from the personal garbage bin rather than from /tmp. A preference could control this behaviour of sysvinit to be turned on or off.

I guess your point is that this "bug" resides somewhere else. So maybe it is a feature request instead. It could not be implemented as separate script and linked in as /etc/rcS.d/S32copy-savedintmp or similar executed before the actual cleanup because at that point the disk is not mounted.

I don't think it's a good idea to pretend that this really fixes the issue, so I'd prefer us not to pretend that it does.

Maybe it's a suitable temporary fix. Someone more expert than me should judge whether the pros outweight the cons. I'd imagine that some people might see this as breaking the temporary files concept.

Moving files behind the user's back is a very bad practice.

Doing so looking at their permissions is fragile.

My two eurocents.

Murray:
I agree that some people may consider the aproach a bit harsh but compared to fixing lots of userspace application that is used as helperapps for archivers, browsers and such I think it is worth some consideration.

Fixing this is in a lot of applications will introduce more bugs and we will have users that relies on the fact that saving a file is safe, when it is in fact not the case as long as you have some applications still not fixed.

Snark:
I don't understand how removing files behind the users back is a better practice.

Alerting the user that the files have been moved to a certain quarantine directory (I suggest the garabage bin directory) is both user friendly and pragmatic.

Also beeing able to turn it off in the preferences will allow superuses to rely on the system to clean up their mess after reboot.

In any case this is a change I intend to rely on so I wanted to share it.

Removing files in the _temporary_ directory isn't "behind users' back", so it's better : you claim something, you stick to it.

Why not make applications save those files readonly? That way the user will not write to them.

I think this is a Firefox bug. Firefox should discourage storing user files to /tmp directory, just like other programs do.

I am against the hackish fix by making temporary files non-temporary by some arbitrary permission criteria. Even though I think it's a nice temporary hack, it's probably not the real fix for this bug. Changing how /tmp works seriously breaks the logic of things - and what does FHS say about /tmp?

It makes more sense to fix obvious bugs in GUI applications than trying to hide the problems in the more internal parts of the operating system.

Changing package back to firefox based on comments by me, Snark, Murray Cumming, jhasse, Eric Feliksik and seanh.

No problem, don't forget to open bug reports for all other affected GUI apps also then. If MOTU decides to fix this I'd prefer the read-only permission solution on files saved by GUI apps using helper apps. I guess it could work in most cases by just changing the 'umask' in the right place when starting the helper app.

So where is the best place to store these files to? $HOME, $DESKTOP? or even some temp/ folder somewhere in the users profile dir?

How about storing them in
${FIREFOX_DOWNLOAD_DIR}/${USERNAME}AutomaticDownloads by default? (e.g:
/home/sean/Downloads/seanAutomaticDownloads)
Also, let the user specify where the AutoDownloads directory should go ...
maybe some people want to set it as /tmp. (e.g.
/tmp/seanAutomaticDownloads)

"Clear private data ...", (and elsewhere?) should also let people purge the
contents of that directory (probably with some sort of warning first).

On 06/02/07, Alexander Sack <email address hidden> wrote:
>
> So where is the best place to store these files to? $HOME, $DESKTOP? or
> even some temp/ folder somewhere in the users profile dir?
>
> --
> Users should be discouraged from editing temporary files
> https://launchpad.net/bugs/15179
>

OK thanks, I think this report contains enough information to go upstream. For now I add an empty remote bug reference to indicate this. Next submission round, this will go up.

anyone has bugzilla.mozilla.org bug id for this?

Thanks,

 - Alexander

I've just had a user lose data due to this issue. As this is a data-loss bug, I would recommend increasing the severity of it.

Agreed, I don't really see the justification for this begin "medium". People lose essays etc., it is a usability issue leading to data loss.

Is there any way to to get a link to the upstream bug report at firefox bugzilla through launchpad? I'd be interested to see why they rejected it. (I searched Firefox bugzilla for 'Users should be discouraged from editing temporary files' but turned up nothing).

I can't find the Moziall bug either ...
We need to know why they have rejected the bug, but if they aren't going to
fix it, Ubuntu should. Losing a file destroys the user's confidence in the
system.

On 14/05/07, seanh <email address hidden> wrote:
>
> Agreed, I don't really see the justification for this begin "medium".
> People lose essays etc., it is a usability issue leading to data loss.
>
> Is there any way to to get a link to the upstream bug report at firefox
> bugzilla through launchpad? I'd be interested to see why they rejected
> it. (I searched Firefox bugzilla for 'Users should be discouraged from
> editing temporary files' but turned up nothing).
>
> --
> Users should be discouraged from editing temporary files
> https://bugs.launchpad.net/bugs/15179
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Mozilla upstream didn't reject the bug, the bug was rejected in the Firefox product on Launchpad, which is technically upstream of the Ubuntu/Firefox product. It's a particularly confusing feature of Launchpad's.

I don't even think that a bug has been filed for this in the Mozilla bug tracker. Would someone like to volunteer to take care of this?

On Mon, May 14, 2007 at 03:05:48PM -0000, Phil Bull wrote:
> Mozilla upstream didn't reject the bug, the bug was rejected in the
> Firefox product on Launchpad, which is technically upstream of the
> Ubuntu/Firefox product. It's a particularly confusing feature of
> Launchpad's.
>
> I don't even think that a bug has been filed for this in the Mozilla bug
> tracker. Would someone like to volunteer to take care of this?
>

I rejected the upstream bug, because thats not the way we
(mozillateam) mark bugs that need upstream triage. We set mt-upstream
tag. Anyone feel free to drop bugzilla bug number. There should
definitly be one posted already.

 - Alexander

we could download to default Downloads dir ... this of course might produce garbage if you just want to look at read-only docs like pdf.

Yes, I think the general Downloads dir would get too crowded.
What about a personal downloads directory (like was originally proposed),
say ~/.webfiles or ~/.firefox/webfiles? Things downloaded to this directory
should be saved read-only so the user will be prompted to save the file
somewhere else if they edit it (from whatever program they use to edit it).
It should be possible to have this directory automatically cleaned when the
other personal data is cleaned, probably with a warning though, like when
forgetting saved passwords (I think that is the one with the warning).
There should be a way, for those who like the current behaviour, and know
what they're doing, to change this directory back to /tmp.

On 15/05/07, Alexander Sack <email address hidden> wrote:
>
> we could download to default Downloads dir ... this of course might
> produce garbage if you just want to look at read-only docs like pdf.
>
> --
> Users should be discouraged from editing temporary files
> https://bugs.launchpad.net/bugs/15179
> You received this bug notification because you are a direct subscriber
> of the bug.
>

On Tue, May 15, 2007 at 04:15:50PM -0000, Sean Kennedy wrote:
> Yes, I think the general Downloads dir would get too crowded.
> What about a personal downloads directory (like was originally proposed),
> say ~/.webfiles or ~/.firefox/webfiles? Things downloaded to this directory
> should be saved read-only so the user will be prompted to save the file
> somewhere else if they edit it (from whatever program they use to edit it).
> It should be possible to have this directory automatically cleaned when the
> other personal data is cleaned, probably with a warning though, like when
> forgetting saved passwords (I think that is the one with the warning).
> There should be a way, for those who like the current behaviour, and know
> what they're doing, to change this directory back to /tmp.

Then why not just save as read-only and keep the downloads in tmp?

 - Alexander

Because sometimes they download something, and expect to be able to find it
later ...
I think this is how a desktop background got disappeared in one case.

On 15/05/07, Alexander Sack <email address hidden> wrote:
>
> On Tue, May 15, 2007 at 04:15:50PM -0000, Sean Kennedy wrote:
> > Yes, I think the general Downloads dir would get too crowded.
> > What about a personal downloads directory (like was originally
> proposed),
> > say ~/.webfiles or ~/.firefox/webfiles? Things downloaded to this
> directory
> > should be saved read-only so the user will be prompted to save the file
> > somewhere else if they edit it (from whatever program they use to edit
> it).
> > It should be possible to have this directory automatically cleaned when
> the
> > other personal data is cleaned, probably with a warning though, like
> when
> > forgetting saved passwords (I think that is the one with the warning).
> > There should be a way, for those who like the current behaviour, and
> know
> > what they're doing, to change this directory back to /tmp.
>
> Then why not just save as read-only and keep the downloads in tmp?
>
> - Alexander
>
> --
> Users should be discouraged from editing temporary files
> https://bugs.launchpad.net/bugs/15179
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Perhaps adding something to the download dialog (where you pick to open it
with an application or save to disk) saying that unless the file is saved to
another location, that it will be deleted when the computer is shut down
would be sufficient.
That, at least, would warn the user, if they read the dialog.

On 15/05/07, Sean Kennedy <email address hidden> wrote:
>
> Because sometimes they download something, and expect to be able to find
> it later ...
> I think this is how a desktop background got disappeared in one case.
>
>
> On 15/05/07, Alexander Sack <email address hidden> wrote:
> >
> > On Tue, May 15, 2007 at 04:15:50PM -0000, Sean Kennedy wrote:
> > > Yes, I think the general Downloads dir would get too crowded.
> > > What about a personal downloads directory (like was originally
> > proposed),
> > > say ~/.webfiles or ~/.firefox/webfiles? Things downloaded to this
> > directory
> > > should be saved read-only so the user will be prompted to save the
> > file
> > > somewhere else if they edit it (from whatever program they use to edit
> > it).
> > > It should be possible to have this directory automatically cleaned
> > when the
> > > other personal data is cleaned, probably with a warning though, like
> > when
> > > forgetting saved passwords (I think that is the one with the warning).
> > > There should be a way, for those who like the current behaviour, and
> > know
> > > what they're doing, to change this directory back to /tmp.
> >
> > Then why not just save as read-only and keep the downloads in tmp?
> >
> > - Alexander
> >
> > --
> > Users should be discouraged from editing temporary files
> > https://bugs.launchpad.net/bugs/15179
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>
>

On Mon, May 28, 2007 at 12:08:35AM -0000, Sean Kennedy wrote:
> Perhaps adding something to the download dialog (where you pick to open it
> with an application or save to disk) saying that unless the file is saved to
> another location, that it will be deleted when the computer is shut down
> would be sufficient.
> That, at least, would warn the user, if they read the dialog.

Which they usually don't do :).

 - Alexander

True enough ... maybe the options should change. Instead of "Open with ..."
and "Save to Disk", there should be: "Open with ...", "Save, and open with
...", and "Save".

Interestingly, I recently found out my mom didn't want to pick "Save to
Disk" because she associated "disk" with needing a floppy disk.
I have opened another bug for that issue ... I don't know if anything should
be done, but I thought it was worth recording:
"Save to Disk" confuses some users
https://bugs.launchpad.net/bugs/117260

Sean

Please do NOT save all files which firefox downloads when you choose 'open' outside of /tmp. The reason you can choose behind 'open' and 'save to disk' is obvious: you don't want to keep stuff you 'open'. If a file is opened by a user and he changes his mind (and edits anyway), however, he should be warned about saving to /tmp. But wouldn't it be much better to do this in the GTK file chooser? Just a yellow bar 'Files in /tmp are temporary' would solve the problem. Only display the bar when the user 'starts' at /tmp, not when he manually goes there. (If he does, he should know what he's doing and the bar will annoy him.) Give the user who understands the filesystem the option to not show the bar again.

Changing GTK file chooser is much more reasonable and easier than changing every application which might save something to /tmp and let users open it. (These are at least all browser and all e-mail programs.)

On Sat, Sep 01, 2007 at 01:29:57PM -0000, Jeroen van Splunder wrote:
> Please do NOT save all files which firefox downloads when you choose
> 'open' outside of /tmp. The reason you can choose behind 'open' and
> 'save to disk' is obvious: you don't want to keep stuff you 'open'. If a
> file is opened by a user and he changes his mind (and edits anyway),
> however, he should be warned about saving to /tmp. But wouldn't it be
> much better to do this in the GTK file chooser? Just a yellow bar 'Files
> in /tmp are temporary' would solve the problem. Only display the bar
> when the user 'starts' at /tmp, not when he manually goes there. (If he
> does, he should know what he's doing and the bar will annoy him.) Give
> the user who understands the filesystem the option to not show the bar
> again.
>
> Changing GTK file chooser is much more reasonable and easier than
> changing every application which might save something to /tmp and let
> users open it. (These are at least all browser and all e-mail programs.)
>

The current idea is to save files for "open" in read-only permissions
so the editor will complain to the user when he tries to save the
file.

This is the best solution for this whole situation and i will
probably implement this at some point. Probably this won't make it
into gutsy ... but who knows.

 - Alexander

My dad spent four hours yesterday working on an extremely important document firefox ->open with ->open office, being very sure to hit 'save' very often, as this was a _VITAL_ document. Turns out, it got put in /tmp and wiped. His confidence in both Ubuntu and OpenOffice is completely gone, and he went into a many minute rant on how disheartening it was and telling me to wipe Ubuntu from this hard drive.

I'm afraid I need a fix now. Can someone tell me how to configure the software to prevent this from being able to happen again, without waiting for the developers to fix the bug? And also-- this bug needs to be maximum severity. Data loss is a completely unacceptable type of problem. <email address hidden>

Checkout my comment above, the provided suggestion fixes the deletion part of the problem for all programs saving downloaded stuff in /tmp:

https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/15179/comments/11

However it is a bit controversial so you are at your own, it works for me though.

// Joakim

Firefox should have in its preferences a checkbox to "make files opened from the web read-only" and that box should be ticked by default.
There should also be a way to set the directory where it downloads stuff opened (as oposed to saved) and the default should be /tmp

You can't save a read-only file on openoffice. So people would be forced to use "Save as".

The /tmp warning on gnome save dialog would do the rest of the trick.

Sounds good to me :)

Could you do the read only thing with an extension?

This is an old issue.. but I have some new information....

The problem is also present in IE.. BUT with a work around.

HKCR\Excel.Sheet.5\BrowserFlags
HKCR\Excel.Sheet.8\BrowserFlags
HKCR\Word.Document.6\BrowserFlags
HKCR\Word.Document.8\BrowserFlags
HKCR\MSProject.Project.8\BrowserFlags
HKCR\PowerPoint.Show.8\BrowserFlags

Set the values of BrowserFlags to Dword "a"

this will force IE to open the documents in a seperate window as a read-only file.

Okay, somebody put a bounty on this. How much is it going to cost me?
Endless frustration isn't a cost I'm going to accept.
So what'll it be? $50? $100? What do I have to pay to not have edited
documents getting wiped out with no warning?

Let's see.. assuming that 7 hours of work have been lost due to this bug, in
our household alone, that amounts to about..
$80 this bug has cost us so far. Good gosh, people-- can I plunk down
another 80 here, or do I just wait for it to bite us again?

I'm speaking as one who has learned what not to do. I save things to
/locations/. You shouldn't have to worry about that, and old habits die
hard. All those people out there who don't know what's going on are going
to go away thinking 'Linux eats files, no wonder people don't use it.'
I think that's a horrible shame.

Ubuntu needs to make all files placed in /tmp by web browsers read only, and
that has to be default behavior. The people losing documents and the script
ninjas aren't the same group, for the most part.

Seems to be fixed.
By the look of it, firefox now marks things in /tmp read only.

Thank goodness for that.

This is fixed in Firefox 3, but is still present in Firefox 2. Opening task for firefox-2 package.

My mistake. Source package for firefox-2 is firefox. Reopening the task. Sorry.

Yes it is fixed in firefox 3. I was very pleased to see that.

we have a patch for this in thunderbird. we should try to get this applied upstream.

adding firefox-3.0 task as fix released to document that this is fixed in ffox 3.

No more fixes for Firefox 2.

this is fixed in tbird 3 ... temp files are now read-only.