f-spot changes timestamp in an incorrect way

I can confirm this behavior. I believe it is already reported upstream (Gnome bugzilla #332025)

thanks for your answer.
i read in the bug tracker 332025 (comment 14), that there is a "patch"
ported to version 4.1.

do your know where i can get it?

thanks
gernot

Am Freitag, den 14.12.2007, 08:56 +0000 schrieb Stuart Bishop:
> I can confirm this behavior. I believe it is already reported upstream
> (Gnome bugzilla #332025)
>
> ** Bug watch added: GNOME Bug Tracker #332025
> http://bugzilla.gnome.org/show_bug.cgi?id=332025
>
> ** Also affects: f-spot via
> http://bugzilla.gnome.org/show_bug.cgi?id=332025
> Importance: Unknown
> Status: Unknown
>

Is this currently being worked on in upstream? As far as I can tell, it will still affect Hardy.

Looks like this is going to affect Intrepid too :-(

No 'correct' fix from upstream yet. There are a couple of unofficial patches, but I don't think they have been packaged for Ubuntu.

Since this bug corrupts user data I think it should probably have a higher importance than "Low".

I don't know how to link this to more bugs in the gnome bugzilla, but here are a few more bugs that are basically duplicates (although not marked as such):
http://bugzilla.gnome.org/show_bug.cgi?id=329588
http://bugzilla.gnome.org/show_bug.cgi?id=340899
http://bugzilla.gnome.org/show_bug.cgi?id=340903
http://bugzilla.gnome.org/show_bug.cgi?id=454082

This bug has been open upstream for over 2.5 years now.

Can we get one of the unofficial patches into Ubuntu?

Also:

http://bugzilla.gnome.org/show_bug.cgi?id=480615
http://bugzilla.gnome.org/show_bug.cgi?id=532668

I'm bumping importance - it seems to fulfill the criteria of a high importance task due to data loss - "Has a severe impact on a small portion of Ubuntu users (estimated)". I suspect it is a large portion of Ubuntu users though.

I believe we have actually two bugs here:
1) some dates aren't converted correctly when displayed, and
2) the EXIF DateTimeOriginal is modified even though f-spot should never modify it automatically.

Now, 1 is annoying but not really that bad, whereas 2 is what corrupts the user's data and is thus quite bad.

Is anything being done about this? F-Spot is touted as a major feature of Ubuntu:
http://www.ubuntu.com/products/whatisubuntu/810features/photos/

but this bug ruins date and time data attached to imported photos, and for good. It makes F-Spot completely unusable for me since I want this information intact. I imagine there are few, if any, people who feel differently. It seems as though this should be considered of High importance at the Gnome bug-list, yet there's been no activity at all. That is, as far as I can tell. I see the "attachments" at the bottom of the Gnome Bugzilla page but don't know what to make of them.

It looks like the first step is to elevate the Priority and Severity of the bug:
http://live.gnome.org/Bugsquad/TriageGuide#head-a30bd0d8437bffda426b7aba01a1f9ac32acb0c5

Is that right?

Or perhaps it would be better to drop into the #bugs IRC channel to see if I can generate some discussion on this topic:
http://developer.gnome.org/projects/bugsquad/

Anyway, if there's any way I can help please let me know. I have no programming training, but don't mind learning.

I second bododod's comments - I have put up with this bug for over a year now. It is especially bad for someone who then want's to correlate GPS data (geotag) there photos.

How can we get this bug fixed before Jaunty?

for this bugs it's better to comment on the upstream bug tracker, please do it at http://bugzilla.gnome.org/show_bug.cgi?id=332025, will raise the priority of the upstream bug as well, thanks you.

I had some thoughts on this earlier today, as I was manually correcting the timestamp on about 2,000 photos that F-Spot chose to corrupt for me. I'm commenting here because I believe that something should be done about this in Ubuntu until upstream comes up with a solution. I'm not holding my breath, because I distinctly remember running into this problem back in about 2006. Looking at the upstream bug, it looks like this has been open for at least that long.

Upstream doesn't seem to have a clear idea of what to do about this, and they seem to have rejected the obvious (to me) solution of not touching the timestamp. I'd love to see a checkbox; "Modify timestamps during import?"

Barring that, however, there are patches available to F-Spot to cause it not to modify timestamps. Is it possible for Ubuntu to distribute F-Spot with one of these patches applied?

At the very least, I'm going to study up on deb packaging and see if I can't roll my own patched F-Spot package.

I don't mean to stir up any trouble here, but some noise needs to be made about this, and something needs to get done.

I agree that this bug has gone on for way too long for something so trivially fixable; I would half tempted to flex my C# coding skills on this one if there was a hope of any such patch being accepted.

For anyone who needs to restore the original EXIF dates and times without restoring from backup, the following command should do it.

exiftool -r "-CreateDate>DateTimeOriginal" *.jpg

(-r option for recursing into lower directories)

Taken from this comment at Gnome Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=340903#c19

The exiftool method is what I used to fix my corruption. Unfortunately I had some photos that had already been adjusted because my camera had the wrong date set for quite a long time. I forget the exact steps I took, but the end result was all of my photos being off by at least a couple hours. Stupidity on my part mostly.

In short, if you use the exiftool tip, make sure the CreateDates are sane to begin with.

If an up-to-date branch of F-Spot were created without this timestamp modification "feature", could it possibly be accepted in Ubuntu, either as a replacement, or a separate version?

why couldn't that go upstream too?

to reply to the question ubuntu is not likely to use a change not accepted by GNOME on this issue

In regards to #18, The F-Spot developers do not agree with the "Don't automatically alter timestamps" solution.
They are working to develop a solution where F-Spot will alter timestamps in a "correct" way.

This is the reason for my question, to see if this issue could at least be fixed within Ubuntu for the interim. However, I definitely understand why Ubuntu would not want to maintain a version of F-Spot separate from the official.

For all those who are interested, I am currently testing an Ubuntu package of F-Spot which is patched to not alter timestamps, except when asked to do so via the usual "Adjust Time..." dialog.

This is a standard Ubuntu Karmic build of F-Spot 0.6.1.4, with all automatic timestamp altering removed.

You may find it in my PPA here: https://launchpad.net/~smcgrath23/+archive/smcgrath

Please note that I can't provide much support for this package aside from updating to new versions when released. However, there should be no new issues with this version, as the patch is relatively trivial.

Regards,
-Steve McGrath

I'm attaching the patch I'm using for F-Spot to not automatically adjust timestamps. Just in case Ubuntu ever wants to just temporarily fix this downstream for now, or if anyone just wants to take a look and hack away.

This is the patch I'm using in my PPA packages of F-Spot, it applies cleanly against F-Spot 0.6.1.5.

I've posted a link to Steve's patch upstream.

I do think that Ubuntu needs to address this (locally or backported from upstream), or f-spot bumped to universe. Products with data loss bugs affecting a large number of users that have been open for 6 years don't really belong in main.

comments about dropping default applications to universe because of a bug are not really constructive suggestions there

Maybe this isn't the right place for that particular discussion, but the discussion should be had somewhere, and I don't see how it could end any other way than either for f-spot to be fixed or for it to drop to universe/multiverse. It's simply unacceptable that a default application knowingly destroys user data year in and year out.

Thank you a lot Steve for the modified package.
F-spot behaviour of incorrectly modifying the exif data is annoying.

Hi,
Thank you for the package! Imports no longer get modified! :-)

However... there is still one problem left:

After correcting the already imported pictures with the command

exiftool -r "-CreateDate>DateTimeOriginal" -overwrite_original FOLDERNAME

the time inside the exif-data is all right, but the f-spot time is not updated as it is saved inside the database.

=> Does anyone know how to update the f-spot time so that f-spot will show the right time? Is there any way to update the database with the corrected times?

The only (easy) way to get the times right in F-Spot's DB again is to remove and re-import your pictures, unfortunately.

It would be possible to modify the times in the DB directly, a script could be written to adjust them "behind F-Spot's back", but that's a little beyond me right now.

Google around a bit though, someone may have already written such a script. I actually think I recall seeing one, although I have no idea where.

Thank you for bringing this bug to our attention. However, a paper cut should be a small usability issue , in the default Ubuntu 9.10 install , that affects many people and is quick and easy to fix. So this bug can't be addressed as part of the project.

not a paper cut read comment#10 upstream

For further info about papercuts criteria , pls read > https://wiki.ubuntu.com/PaperCut

Don't worry though, This bug has been marked as "invalid" ONLY in the papercuts project.

Today I found this open letter (http://daniel-bartholomew.com/wordpress/2009/10/f-spot-considered-harmful/) to F-spot devs. Perhaps it is time to address this issue.

To whom it may concern,

Data corruption is ALWAYS a critical problem but you list bugs 340903 and 454082 as “UNCONFIRMED” with a severity and priority of “Normal”.

UNCONFIRMED? Normal? Who are you kidding? Data corruption is always critical and these bugs are years old and have been confirmed in your own bugzilla by dozens of users.

Regardless of whatever reason you had for introducing this stupid date-changing “feature”, you never change EXIF data unless the user expressly tells you to. That’s basic common courtesy.

You’ve known about this issue for over three years. You need to grow up, acquire a clue, and fix F-Spot’s terrible and destructive behavior. Yesterday.

Until then I will distrust F-Spot and anyone who says it is anywhere close to being a good, decent, or even “ok” photo manager. You and others keep telling me that F-Spot is awesome, that F-Spot is great, that it is the best Linux photo manager. I no longer believe you. From now on F-Spot is not getting anywhere near my photos. I’ve written about you before but I take all the good things I said then back. I was younger, more impressionable, and foolish. But those are just excuses. The fact is I was wrong. Yes, you appear to have some nice features, but your core has some rotten bits and I don’t eat rotten apples (even if only bits of them are rotten), I throw them away.

Goodbye,

Daniel Bartholomew

Just to "ping" this bug and stress its importance:

Lucid release is near and Ubuntu is shipping (again) a photo manager (its "official" photo manager...) with a critical bug which cause (VOLUNTARY) DATA CORRUPTION. Yes, data corruption: no other definition possible, because the software do not tell the user that it's going to modify its data.

PLEASE, THINK ABOUT THIS. REALLY, PLEASE.

The issue on this one is not to think about the issue it's to understand why f-spot does the things the way it does now. The suggested change before seems to change code over the import tags update. What would the changes mean for already imported photos, does anybody why f-spot try to change the tag? What would be wrongly displayed otherwise?

As far I understood, developers want enforce an absolute order in the photo collection, so that photos are displayed in real shoot order (a photo taken at 1.00 PM in London would be displayed after a photo taken at 1.30 PM in Rome). Is that useful? I think it is completely not: (almost) no one travel so fast and have time to shoot photos... I think it is just the classical "linux nerd thing", like the ones that scared "normal users" for years: plainly a LACK OF COMMON SENSE. The proof is that no other photo manager (think Picasa...) does a crazy thing like this. Isn't Ubuntu Linux for human beings? Developers, anyway, are completely deaf to a critical bug standing there from 2006 (they just say "we are thinking about a good solution"; in the meantime they corrupt user data...) (<RANT>and just to mention the care they have for users base, take a look to LP #204011</RANT>).

As Delcroix himself wrote upstream (https://bugzilla.gnome.org/show_bug.cgi?id=340903#c4)

"whatever the part of the world the photo is shot, when I shoot a clock saying 'it's noon', f-spot should say 'the photo was
shot at noon'".

I guess the majority (almost all?) of users set their camera to local time, so the common sense suggests to leave things unchanged; but of course I can imagine that a nerd sets its camera to UTC... (go to supermarket, ask someone "What's UTC?", then take a photo of his face; obviously, set your camera to UTC...).

Implication in changing the code I can guess:

- corrupted photos would stay corrupted, of course;
- new photos would be correctly imported.

Possible solution to fix things:

1. delete the entire database, fix photos tags copying EXIF CreateDate to DateTimeOriginal, as suggested in comment 27 and then reimport all photos;
2. fix photos tags and then fix the database accordingly (data displayed in F-Spot are read from db, not directly from EXIF).

In both cases, likely the directory tree would become inconsistent (somehow related to LP #63393); so maybe "the best thing" would be:

1. move the entire tree
2. delete the db
3. fix tags
4. reimport all photos with copy option on
4. delete the old (moved an duplicated) tree

Yes, I know, it is quite invasive... But the more time passes, worse things will get. Simple alternative would be leave alone damages done and fix things only for future imports. There are (small?) chances of misordered photos in the "boundary time", but that would be limited to a few hours interval.

This hacking of my exif timestamps is affecting me in show-stopping ways. F-spot needs to offer a checkbox to turn this off, otherwise I must discontinue using it. I'll also have to warn everyone else about it too, in case it effects something they're doing too. Why can't this be fixed?

It looks to me like this could be fixed by simply not writing out EXIF.OriginalDateTime to the first version of the file (named "Original") imported by F-Spot. That version is marked as protected, and should be read-only anyway.

As far as I can tell, F-Spot only reads the tags once, on import, and uses the database for further lookups.

This bug was fixed in the package f-spot - 0.6.1.5-2ubuntu5

---------------
f-spot (0.6.1.5-2ubuntu5) lucid; urgency=low

  * debian/patches/ubuntu_add_save_and_undo.patch:
    + Save over existing files more safely.
    + Save orientation where possible.
  * debian/patches/ubuntu_add_other_files_in_directory_in_view_mode.patch:
    + Watch directories that f-spot is viewing, and add newly created images to
      the viewer.
  * debian/patches/ubuntu_only_update_timestamp_of_unprotected_versions.patch:
    + Only write out DateTimeOriginal if the file is an unprotected version.
      The initially imported file is a protected version which is not written
      to. Prevents the most obnoxious part of (LP: #175191)
  * debian/patches/ubuntu_handle_broken_uris_to_view_mode.patch:
    + Catch exceptions interpreting the paths passed to the --view option.
      (LP: #513252)
  * debian/patches/git_fix_soft_focus_memleak.patch:
  * debian/patches/git_fix_straighten_editor_memleak.patch:
    + Fix memleaks in straighten and soft-focus editors (LP: 378954).
      Patches taken from f-spot git.
 -- Christopher James Halse Rogers <email address hidden> Thu, 18 Mar 2010 10:50:48 +1100

This is now fixed for real in the new upstream version 0.6.2, using the patch that I was advocating by Paul Wellner Bou.

The new version simply does not alter EXIF timestamps, which is arguably the correct behavior.

What are the chances of seeing 0.6.2 in current Ubuntu as an SRU?

0.6.2 has quite some changes, it will be consider for a sru but it might take some time

Well I am a more than a little confused... So I see that F-Spot does not appear to change the exif information of my pictures but importing them still causes the time shift on the date/time when viewed in the program and in the creation of the folder archive. This is a very minor improvement to me. Why hasn't this been taken all the way home?

I have 0.6.1.5-2ubuntu6 installed and I assume 0.6.1.5-2ubuntu5 does this the same way.

Steve, does your PPA's version behave the same as it did before 0.6.1.5-2ubuntu5? That was rational. I think I will try it again. Will you be keeping it around still even though this bug is technically fixed?

The current "fix" in Ubuntu's released version doesn't entirely solve the problem. It *is* solved in 0.6.2, the new upstream release. They essentially just incorporated the same patch my PPA package uses into the mainline code.

I will attempt to keep my PPA packages up to date as time permits, until 0.6.2 is in Ubuntu. I imagine it will be in Maverick, but I am hoping it will be backported to Luicd as well.

Pushed to -proposed:

f-spot (0.6.1.5-2ubuntu7) lucid-proposed; urgency=low

  [ Martin Mai ]
  * debian/patches/git_dont_delete_emailed_files_after_a_fixed_time-out.patch:
    + Leave it up to the os to clear emailed files in /tmp/ (LP: #112684)

  [ Didier Roche ]
  * debian/patches/ubuntu_only_update_timestamp_of_unprotected_versions.patch:
    - deleted as it has some corner cases
  * add git_never_touch_photo_timestamps.patch to fix timestamp incorrectly
    imported (LP: #175191)

Test Case:
 - install the version from proposed
 - click on an image
   * try to send a photo attached to an email with file -> send
   * click on create to fire up thunderbird
   * come back to f-spot, and click on another photo
   * then, switch to thunderbird and send the email
 - do subsequent imports and see that the metadata (import date) isn't touched

Accepted f-spot into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

SRU Verification for Lucid:
I have reproduced the problem with f-spot 0.6.1.5-2ubuntu6 and have verified that the version of f-spot 0.6.1.5-2ubuntu7 in -proposed fixes the issue.

Marking as verification-done

This bug was fixed in the package f-spot - 0.6.1.5-2ubuntu7

---------------
f-spot (0.6.1.5-2ubuntu7) lucid-proposed; urgency=low

  [ Martin Mai ]
  * debian/patches/git_dont_delete_emailed_files_after_a_fixed_time-out.patch:
    + Leave it up to the os to clear emailed files in /tmp/ (LP: #112684)

  [ Didier Roche ]
  * debian/patches/ubuntu_only_update_timestamp_of_unprotected_versions.patch:
    - deleted as it has some corner cases
  * add git_never_touch_photo_timestamps.patch to fix timestamp incorrectly
    imported (LP: #175191)
 -- Didier Roche <email address hidden> Wed, 09 Jun 2010 10:43:14 +0200