605417 - Stop opening attachments read-only; instead, track modification dates

Status: NEW

(MailNews Core :: Attachments, defect)

Description

[Gervase Markham [:gerv]]

Bug 220808 changed attachments to open read-only. In applications, including Openoffice.org, this severely restricts the function of the application - you can't make any changes to the file, such as adjust column sizes in Calc or improve the formatting in Writer.

Furthermore, once you are in that situation, fixing that problem is difficult. If you go to "File | Save As...", and click "Save", it asks you if you want to overwrite the document. You say Yes, and then it tells you "Error: document was opened read-only". You have go to through the process again, and pick a new name for the file. Except that you may like the current name. So what you actually have to do is pick a new _directory_. All of this is hassle, particularly if all you want to do is drag a few column widths around, and don't actually want to keep the data long term - and so, a temporary directory is an entirely reasonable place to keep it. I have to have _two_ temporary directories to solve this problem - one for Thunderbird to put files in, and another to save them in so I can write to them.

(There is an "Edit Document" button in OOo, but it's not very discoverable.)

An alternative solution to the dataloss risk is this: somewhere, we must keep track of "temp" files to delete on exit. Add an additional piece of metadata, which is the timestamp of the file after it was written. If that has changed, don't delete it.

We should consider reversing the fix of bug 220808 and implementing this instead.

Gerv

Comment 1

[Magnus Melin [:mkmelin]]

That won't help in case you open the file, close tb and then do modifications.
Then again, i'm not sure "we" delete it, at least on linux it's stored in /tmp which is anyway cleared on boot by the os.

Comment 2

[Gervase Markham [:gerv]]

Or, even easier, check to see if the creation time and the modification time are the same. No need to store any data at all.

Gerv

Comment 3

[Rob Janssen]

Not deleting the files is not a good solution.
The files are in the %TEMP% dir, which is prone to cleanout for other reasons than the application exiting.
Also, we must not encourage people to use the %TEMP% dir to store their documents.

The original solution of making the documents readonly is quite good.  If some people do not like that, there should be a configurable directory where those documents extracted from attachments are stored instead of in %TEMP%.   This could default to "My documents" on Windows.
THERE one can keep documents without the risk of them being deleted by other procedures.