Created attachment 59568 [details] [review]
Patch agains CVS

Original file
=======
-rw-r--r--  1 bengt bengt 62455 2005-12-04 00:51 RenameGui-Draft1.jpg

Normal imported file
-rw-r--r-- 1 bengt bengt 62455 2006-02-17 22:34 RenameGui-Draft1.jpg

With attached patch
-rw-r--r-- 1 bengt bengt 62455 2005-12-04 00:51 RenameGui-Draft1.jpg


Patch summary below
         System.IO.File.Copy (path, dest);
+
+       // Set the creation date/time to same as original.
+       DateTime createdate = System.IO.File.GetCreationTimeUtc (path);
+
+       // SetCreationTimeUtc do not seem to work.
+       System.IO.File.SetCreationTimeUtc (dest, createdate);
+
+       // SetLastWriteTimeUtc sets Creation and Last Write time.
+       System.IO.File.SetLastWriteTimeUtc (dest, createdate);

This patch should also fix bug #170771

Bengt, I'm a little unhappy with this patch mostly because it isn't clear to me exactly what mono is doing in this case since it maps change time to CreationTime which is wrong to begin with.  On the other hand it isn't likely to cause too many problems....

True, but while we wait for Mono to fix the problem...
Also, perhaps we should raise a bug for Mono on this one or?
And as soon as they have fixed their issue, then F-Spot can change accordingly (with a pre-compiler directive? CONFIGURE?)

Any more comment on this one?

Again, I see no problem in implementing a workaround while we wait for the underlaying code to be fixed. It can be fixed with a CONFIGURE directive or?

We do have a number of people out there with bad/no exif timestamp, but they have taken care to keep the unix filestamp.

This bug would fix bug #331537

Should the copy have the same timestamp as the original? I don't think so. After all, it's a copy.

But it is a copy of a photo, which represents an occurance in time.
There has been numerous problems when people had F-Spot importing photos where the meta data was not correct but the person had taken great steps to preserve the correct timestamp on the photo.

Will you keep a copy in F-Spot and the original somewhere else?
Or simply delete the other photo (original) and only keep the photo in F-Spot (and manually or with F-Spots (bug #325381) help take backups)

Sorry, I'm so used to EXIF telling me when the picture was taken that I had zapped the fact that one could want to use the file timestamp for that.

But in that case, I would like it better if f-spot updated/created the metadata, rather than "lying" about the file timestamp. Which brings us back to http://bugzilla.gnome.org/show_bug.cgi?id=331537 and I now understand better your overall idea.

Sounds like we need to agree on what is the "right thing to do" here. I like the idea of creating the metadata if it doesn't exist yet, based on the filesystem data. I guess if that was done, you wouldn't object to the file timestamp being updated, would you?

I'd like to hear other ppl's opinion on this matter, to see if I've missed sthg.

Yes for sure, F-Spot should (I think) create the metadata timestamps (those that are missing (datetime, DateTimeOriginal and/or DateTimeDigitized) since if they do not exist, the timestamp should be set (perhaps configurable though).
DateTimeDigitized / DateTimeOriginal should be the file's creation date, and DateTime the current time. This should be solved in bug #331537

But I still think that the photo's timestamp should be preserved.
Then again as long as the EXIF timestamp is correct, that should be enough.

fixed in stable and head.

Sorry, but I'm not sure it's fixed in stable.
I'm using F-spot 0.1.11, if it's really what 'stable' should be. Sorry if it's not the case.

I have an old photo without any Exif data, but the file is original, so it has the real created date.

If I import in F-spot, the copy has a new created date, but F-spot places the photo in the right directory, and display the real created date. However, I don't see any new Exif data with the date, and if I reimport the photo again in F-spot (from this copy, not from the original), the photo is placed in the wrong directory, as it has now a wrong creation date. 

How to reproduce:
-find an old photo, without exif data. Let's say it was taken in 2000
-import it in F-spot. THe new file has a created date in 2006, but it's placed in the 2000 directory in Photos/, and in F-spot, you see the real created date in the left hand side info. 
-copy this new file somewhere, and import this directory
-the copy will be placed in the 2006 directory, loosing all info about the real creation date and time.

I know it's a very unlikely situation, but it happened to me when I wanted to import some photos again on another computer. Fortunately, I kept the original photo, so I can reimport from it. However, if someone has for example 5000 scanned photos, import them, then delete the original copies, the only way for him to keep the created date is to add the Exif data or change the date for ALL the files. To me it's quite annoying. And you loose the creation time also...   

Stable, that is 0.1.11, was release a number of months ago, and no releases took place after that for various reasons.
CVS has been updated with this code though.

You could try to run CVS Head if you like, for more information please see : http://f-spot.org/How_To_Build

Hopefully a new release will take place fairly soon though.

Thanks for the comments Bengt. In this case, I don't think this bug should be closed then, as it's still not keeping the unix timestamp after the first import. 

*** Bug 351621 has been marked as a duplicate of this bug. ***