[Digikam-devel] [Bug 284585] New: rsync compatibility when changing exif orientation and not modification time.

[Tex]

https://bugs.kde.org/show_bug.cgi?id=284585

           Summary: rsync compatibility when changing exif orientation and
                    not modification time.
           Product: digikam
           Version: unspecified
          Platform: Gentoo Packages
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: general
        AssignedTo: digikam-devel at kde.org
        ReportedBy: Tex2571 at hotmail.com


Version:           unspecified (using KDE 4.6.5) 
OS:                Linux

I like to keep modification dates unchanged.
I also use exif orientation changes and rsync which checks for file size and
modification date differences.

After the first meta-data change (when digikiam adds some digikam version to
the metadata) future exif orientation changes do not change the files size.  If
modification time changes are also disabled then rsync sees no change in the
file (without enabling full checksumming, and who wants to do that?)

It would be kind of spiffy if digikam could check this, notice the unchanged
file size and time and add a single byte of padding somewhere. Maybe if the
padding gets absurd it could eventually wrap back to zero, but that's probably
not even an issue practically.

OK it's a self-inflicted corner case, and probably very egocentric, but that's
my funny wish. ;)

Reproducible: Always

Steps to Reproduce:
-unselect update filetimestamp when metadata are saved
-change exif orientation once
-rsync the file to somewhere
(works fine if the file was never previously modified by digikim)
-change exif orientation again
-rsync again, does not detect the change and does not transfer the file.


Expected Results:  
I fully expect the present results.
But I'd like the second rsync to work.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.