Re: Small change in image-dired.el

[Mathias Dahl]

>  What is the rationale for such a "feature"?

See below.

>  Generally, modifying a file
>  and then changing its timestamp back to what it was is a good way to get
>  in trouble (many programs assume that if the timestamp hasn't changed,
>  then the file hasn't changed).

Yes, I agree, mostly.

>  I'm not necessarily opposed to it, but I'd first like a compelling
>  evidence that this is really the right way to solve the
>  original problem.

I think the only "problem" was that Stefan R was used to work in a
certain way with his photos, and the rotation messed up with his
scheme. I suspect for him that a rotation is an operation that can be
neglected from a change viewpoint.

Here is our original conversation:

----

from    Stefan Reichör
to      Mathias Dahl
date    Sat, Jun 17, 2006 at 10:31 PM
subject Improvement for tumme-rotate-original
mailed-by       utanet.at
                
Hi Mathias!

I try to use tumme to organize/view my photo collection.
My photos all keep the timestamp when they were shot.

I modified tumme-rotate-original in a way that the time stamp is
preserved. It would be nice, if you could add this functionality!

Stefan.

[patch removed]

from    Mathias Dahl
to      Stefan Reichör
date    Sun, Jun 18, 2006 at 8:53 AM
subject Re: Improvement for tumme-rotate-original
mailed-by       gmail.com
        
Thanks for the patch, I'll think about it. Personally I never trust
the timestamp of a file because I have found out too many times that
it has been modified in transit, when copying, moving, FTPing,
zipping, whatever... What I do instead is trust the EXIF data in it,
make sure that it is always preserved (tumme does that by default). I
also rename all the photos I take with my camera using the internal
timestamp so that the names will be unique and sorted in the correct
order in dired etc. Tumme has a command for this,
`tumme-copy-with-exif-file-name'. Maybe that is something you would
like to try?

Also, the touch command is not available on w32 so this would have to
be an option or we would have to find a suitable replacement command
that works there.

I suggest you keep your fix in your .emacs and I *might* try merge it
into tumme.el when I have the time.

Again, thanks for the suggestion!

from    Stefan Reichör
to      Mathias Dahl
date    Mon, Jun 19, 2006 at 6:23 AM
subject Re: Improvement for tumme-rotate-original
        
Hi Mathias!

> Thanks for the patch, I'll think about it. Personally I never trust
> the timestamp of a file because I have found out too many times that
> it has been modified in transit, when copying, moving, FTPing,
> zipping, whatever... What I do instead is trust the EXIF data in it,
> make sure that it is always preserved (tumme does that by default). I
> also rename all the photos I take with my camera using the internal
> timestamp so that the names will be unique and sorted in the correct
> order in dired etc. Tumme has a command for this,
> `tumme-copy-with-exif-file-name'. Maybe that is something you would
> like to try?

Thanks for your ideas. I try to keep the date correct for my pictures.
And that works for me. Thanks for the hint about the EXIF data.

I also have a small python script to rename my pictures, using the
date. It is nice to see that date on the back of the pictures when I
order them from a photo shop.

> Also, the touch command is not available on w32 so this would have to
> be an option or we would have to find a suitable replacement command
> that works there.

You could try, if touch is available and use it only then. Something
like tumme-has-touch-command.

> I suggest you keep your fix in your .emacs and I *might* try merge it
> into tumme.el when I have the time.

That is fine with me. I think most users will prefer this behaviour.

----

As you can see, I too think EXIF should be trusted rather than the
timestamp. Still, I thought the feature sounded OK to have and should
not hurt anything, especially with the new variable
introduced. Granted, even if the change is quite small, it increases complexity,
so I won't argue about it being included.

/Mathias