After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 601711 - F-Spot deletes temporary image files too early when sending mails
F-Spot deletes temporary image files too early when sending mails
Status: RESOLVED FIXED
Product: f-spot
Classification: Other
Component: Export
0.6.x
Other Linux
: Normal normal
: 0.7.0
Assigned To: F-spot maintainers
F-spot maintainers
Depends on:
Blocks:
 
 
Reported: 2009-11-12 15:55 UTC by Pedro Villavicencio
Modified: 2010-05-26 20:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch to stop deleting temp files. (2.31 KB, patch)
2010-05-14 18:01 UTC, Dave Neary
committed Details | Review

Description Pedro Villavicencio 2009-11-12 15:55:49 UTC
this report has been filed here:

https://bugs.edge.launchpad.net/ubuntu/+source/f-spot/+bug/112684

"How to reproduce 
- In F-Spot: File -> send email
- Now, f-spot creates a temporary jpg-file in /tmp and opens thunderbird. But when you switch back to f-spot and change the perspective (e.g. double-click on another image), f-spot deletes the temporary file and sending mail is not possible anymore..."

"F-spot creates an image directory in /tmp and puts image files in there. If I sent the message quickly, the image is still there and the mail goes out. If I take the time to compose a message, the images disappear and I can't send the email. I haven't been switching back to f-spot to manipulate the photos like the original submitter, I've just been typing emails.

Here's an strace of this happening (is this useful at all?)

The temp directory created is /tmp/tmp7af80db9.tmp/ you can see 3 images created in that directory and subsequently they're unlinked... I was still typing the email!"

"This is explained in the usermanual, under the Send email section: there's a timeout after which the temporary pictures are deleted. The default value is 30 seconds, but can be increased at wish.
The gconf key is /apps/f-spot/export/email/delete_timeout_seconds"

"The temporary folder F-Spot creates (in /tmp in my case) disappears automatically after a short while. When Thunderbird comes to look for it to send the mail, it fails as it no longer exists. This makes it practically impossible to send an image as email via Thunderbird using this F-Spot feature."

"From a usability perspective we cannot expect a user to launch the configuration editor to change this default value. I'll have a look at how it's packaged and see if I can come up with a better default value, say 10 minutes."
Comment 1 Stephane Delcroix 2009-11-20 09:26:13 UTC
1) thunderbirds is to blame here
2) setting to 10 mins will cause /tmp to fill up (in case of someone closing f-spot during those 10 minutes)
3) setting the value to 10 minutes won't fix the issue, just delay it...

any suggestion anyone ?
Comment 2 Vincent 2010-01-02 07:57:28 UTC
(In reply to comment #1)
> 1) thunderbirds is to blame here
Can I know why??? If the file is deleted before Thunderbird send the mail, it is sure that it will failed no? Maybe F-spot should use its own tmp folder, and delete it only when closed, or something like that?
Comment 3 Maxxer 2010-01-09 21:27:24 UTC
(In reply to comment #2)
> Can I know why??? If the file is deleted before Thunderbird send the mail, it
> is sure that it will failed no? Maybe F-spot should use its own tmp folder, and
> delete it only when closed, or something like that?

i.e. Evolution caches the file itself, when you attach a file to the email.



a fix could be to launch thunderbird, and leave a "Export completed" dialog open. When the user closes this dialog, f-spot then deletes the temp files.

Stephane, can this be an acceptable solution?

Looks fair... I export the pics, f-spot fires up thunderbird (or whatever), I send the email and when I'm back to f-spot and hit "OK" the temp files are deleted.
Sure that users should be informed about this behaviour.
Comment 4 Vincent 2010-01-10 06:55:50 UTC
I wonder if it is really needed that F-spot delete the tmp folder. I think that the system do it itself (maybe at shutdown or something like that), so F-spot should just leave the temporary file and do not care about their deletion!
Comment 5 Dave Neary 2010-02-22 20:38:33 UTC
I agree with Vincent (comment #4). It's a mistake for f-spot to assume that the mail programme will make its own cache of the photo. I for one, and my wife, have been surprised by this tmp-cleaning "feature".

The workflow we have is export->send email, then compose the email with text etc, then send. It's just not possible to do that in 30s.

Dave.
Comment 6 Paul Crawford 2010-05-14 13:59:07 UTC
For most LINUX users /tmp is cleared on reboot, so filling that is a minor concern. However, not ALL systems do this, either by choice, or due to a bug (e.g. Ubuntu 9.10 with /tmp in separate partition).

The most obvious method is to have F-spot clear all temp files on exit. It saves worrying about a "reasonable" time-out period, and it sort of makes sense in the 'method of least surprise' rule. If F-spot should crash before then, well we can fall back to the automatic clearing /tmp on boot-up.

Consider a user tries to send an email, they close F-spot early and then are told the wanted file is missing. What are they likely to do? Try again and maybe not close F-spot to see if it now works? That is what I suspect would happen, and so the problem is solved.
Comment 7 Paul Crawford 2010-05-14 14:03:48 UTC
Just to add that "...F-spot clear all temp files..." means all of F-spot's temp files, not others!
Comment 8 Ruben Vermeersch 2010-05-14 14:31:29 UTC
Paul: This could be patched quite easily: collect a list of filenames that need to be deleted at shutdown and do so when shutting down.

Now the question is: what happens when a user closes f-spot before sending the message? That's something I do see happening.
Comment 9 Vincent 2010-05-14 14:45:04 UTC
(In reply to comment #6)
> For most LINUX users /tmp is cleared on reboot, so filling that is a minor
> concern. However, not ALL systems do this, either by choice, or due to a bug
> (e.g. Ubuntu 9.10 with /tmp in separate partition).

I still think this is not the concern of F-Spot to fix OS bug. F-Spot should use the temp folder as a temp folder, and don't care about the deletion of the file, which are the OS responsibility.
Comment 10 Paul Crawford 2010-05-14 14:49:09 UTC
Ruben: The problem is there is no perfect solution, other than Thunderbird (and every possible email client) to cache attached files. As that is not likely, the question becomes: "What is the least problematic solution?"

It has to be one that addresses the problem of keeping the temp file until the user is likely to have sent the message. But equally, it is sensible to avoid polluting /tmp just in case it is not cleared periodically (for whatever reason).

Any time-out is possibly going to be too short (don't you hate web sites that throw an error if you come back an hour or two later and they have timed out?). And if the close F-spot, it has only two possible choices: either remove the file then (same problem as you mention), or leave the file in /tmp (again, a problem).

I think the "remove on close" option is the best of the practical choices there are. To help users, maybe F-spot could put up a short time-out dialogue box on the delete process just so folk know what it is doing?
Comment 11 Ruben Vermeersch 2010-05-14 15:05:11 UTC
So how realistic is the case of filling up /tmp? You're not supposed to email gigabytes of photos anyway, right? Are we so short on space there that this will become problematic?

Like Vincent, I agree that we shouldn't be working around OS bugs, except when they're really a problem. Somehow, I doubt that this case is.

Sounds like simply dropping them in /tmp/ and leaving them there until the OS fixes it is the most suitable solution, in the sense that it will break the experience for the least amount of users. Unless I'm overlooking something here.
Comment 12 Paul Crawford 2010-05-14 15:17:54 UTC
> Sounds like simply dropping them in /tmp/ and leaving them there until the OS
> fixes it is the most suitable solution, in the sense that it will break the
> experience for the least amount of users. Unless I'm overlooking something
> here.

That is probably a safe option, also in those cases where /tmp is not cleared on boot up (like my 9.10 box mentioned) it gradually fills with other stuff anyway, so it *should* be cleared automatically by something!

Of course, there could be an Edit->Preferences choice for this?
Comment 13 Dave Neary 2010-05-14 15:25:08 UTC
(In reply to comment #9)
> I still think this is not the concern of F-Spot to fix OS bug. F-Spot should
> use the temp folder as a temp folder, and don't care about the deletion of the
> file, which are the OS responsibility.

That's missing the point - F-Spot is making an incorrect assumption about mailer programs - namely, that they will copy files when attached to emails. Thunderbird doesn't do this, Mutt doesn't do this, I am sure there are others.

The question then becomes, what should F-Spot do to be a responsible user of /tmp, while performing correctly when attaching photos to emails?

I don't think "set a longer time-out" is the perfect thing to do, since it's not unreasonable to start writing an email at one point, and finish it much later, and I don't think "delete when F-Spot quits" is the right thing either, for the reason that Ruben points out.

It feels to me like the right thing is to let the user take care of their /tmp directory, and not delete files. Other apps appear to follow this norm.

But if you really wanted to fix the bug "properly", then you would watch the file to see if any other applications have it open, and delete it only when there aren't. A quick check shows that Thunderbird doesn't even open thhe file when a copy is attached. The alternative is to patch every single email programme for Linux to have them create link to the original file, and delete their linked copy themselves when they're finished.

In the absence of a perfect solution, a 10 minute or 30 minute timeout before deleting is certainly reasonable & easy to do. Alternatively, as Paul says, leaving the management of /tmp to the user, instead of "F-Spot knows best" could be a good approach too.


Dave.
Comment 14 Dave Neary 2010-05-14 15:26:12 UTC
And please no preference! This would be a classic "unbreak me" preference if ever there was one.

Dave.
Comment 15 Paul Crawford 2010-05-14 15:37:24 UTC
I think it is generally accepted that something has to be done. My own view is any time-out is going to be arbitrary and ultimately limited by the user closing the program. Of if the decision is to clean up /tmp then you might as well do it on F-spot closing.

The alternative of letting the OS clean /tmp on reboot makes a lot of sense, even folk who run 24/7 need to reboot occasionally for kernel patches! In special cases, then just "rm /tmp/*.jpg" is probably a good enough solution.

My suggestion for a user configurable preference was only for "delete temp files on exit" or "leave temp files on exit".

All things considered, the simplest option is to leave the files, and allow OS/user to clean up later.
Comment 16 Ruben Vermeersch 2010-05-14 15:44:51 UTC
(In reply to comment #14)
> And please no preference! This would be a classic "unbreak me" preference if
> ever there was one.

Wasn't going to let that happen :-).
Comment 17 Dave Neary 2010-05-14 16:14:25 UTC
(In reply to comment #15)
> The alternative of letting the OS clean /tmp on reboot makes a lot of sense,
> even folk who run 24/7 need to reboot occasionally for kernel patches! In
> special cases, then just "rm /tmp/*.jpg" is probably a good enough solution.

I would have no problem with F-Spot installing a cron script to do just that in cron.daily.
Comment 18 Paul Crawford 2010-05-14 16:20:06 UTC
> > even folk who run 24/7 need to reboot occasionally for kernel patches! In
> > special cases, then just "rm /tmp/*.jpg" is probably a good enough solution.
> 
> I would have no problem with F-Spot installing a cron script to do just that in
> cron.daily.

While a possible solution you need to make sure you:

(1) Don't remove in-use files, again, what time-out to use?
(2) Don't remove other applications' data.

So you would then have to make sure that F-stop had a more unique file name template, something like f-stop-<random>.jpg and then use 'find' with 'rm' to remove the files with modify time older than a day or so.
Comment 19 Paul Crawford 2010-05-14 16:24:24 UTC
Some sort of chron job command like:

find /tmp -name 'f-stop-*.jpg' -mtime 2 -print0 | xargs --null rm

But my overall feeling is it is overkill to add a chron job unless there is some special reason to foce /tmp cleaning without reboot doing it.
Comment 20 Paul Crawford 2010-05-14 16:37:00 UTC
From a quick look, maybe this is better command:

find /tmp -name 'f-stop-*.jpg' -type f -mtime 2 -delete
Comment 21 Ruben Vermeersch 2010-05-14 16:41:27 UTC
Once again, before we fall into the pit of finding a solution for a problem that doesn't exist: can someone draw me a scenario where this is a real huge problem?

Having such a small /tmp/ that it can be filled up with photos which you're going to email is probably a partitioning error. Unless real users actually email gigabytes of photos.
Comment 22 Paul Crawford 2010-05-14 17:01:24 UTC
> Having such a small /tmp/ that it can be filled up with photos which you're
> going to email is probably a partitioning error. Unless real users actually
> email gigabytes of photos.

That is probably right, the only time I ran out of /tmp space was on a SSD laptop with 4GB '/' and 12GB '/home' partitions, and then it was after some OS release upgrades had swollen the system somewhat.

One of the key reasons for using F-spot's email option is the size reduction, so really we are looking at a 100kB-ish size per image in most cases, and most users won't be emailing 1000s of messages, so I doubt more than 100MB even in bad conditions, and that is kind of trivial for most HDD that anyone will be trying to run an recent version of LINUX and F-spot on.

So my vote is just leave the files and allow the OS to clean up on reboot.
Comment 23 Dave Neary 2010-05-14 18:01:49 UTC
Created attachment 161082 [details] [review]
Proposed patch to stop deleting temp files.

This patch also removes the setting EXPORT_EMAIL_DELETE_TIMEOUT_SEC.
Comment 24 Ruben Vermeersch 2010-05-14 18:16:38 UTC
Comment on attachment 161082 [details] [review]
Proposed patch to stop deleting temp files.

Committed, with a small change to make it build. Thanks.
Comment 25 Ruben Vermeersch 2010-05-14 18:17:38 UTC
So I've pushed Dave's patch. We'll let the operating system clean out /tmp/ for now.

If this really turns out to be a problem, please open a new bug (or reopen this one), but I doubt we'll actually see it happen.
Comment 26 Sebastien Bacher 2010-05-26 16:45:09 UTC
shouldn't you use an user tmp dir rather than the system one? this is somewhat leaking private informations to a common directory, users might not want to let your photos staying around in a system directory...
Comment 27 Paul Crawford 2010-05-26 18:40:37 UTC
On my Ubuntu 10.04 box the /tmp directories are 755 permission, but the files are 600 permission, so I don't see it as a big deal unless the file names were 'unusual' (considering the defaults are for read-access to most places anyway).

User temp directories bring back the issue of eventual clean-up, as you would not have the default action to clear /tmp on booting to be the basic approach.
Comment 28 Ruben Vermeersch 2010-05-26 20:30:32 UTC
Yeah, using /tmp shouldn't be a big issue as long as the permissions are right (need to check that), but I'll happily accept a different solution if it turns out that this is really wrong.