CODEWITHSUNDEEP
timestampbackuprsyncstat
simona
simona

Reputation: 2181

rsync and backup and changing timezone

I back up my pictures from my camera using rsync, using:

 rsync -vzrtl --progress --stats --timeout=0 host destination

Now I was in a different timezone when I did my first backup then I moved to a different timezone and I changed it on my laptop (I use ubuntu 10.04.4). Today I was backing up my pictures and I found that the timestamp were different (I mean the timestamps you can see with 'ls -lt'), so rsync would copy the whole directory (I always run rsync with the option -n first to know the list of files it would transfer). Now this is just stupid, because the files are actually the same. So I changed back to the previous timezone, in fact the file timestamps changed to the same on my camera - this I find weird somehow.

After I move to the previous timezone, I found that the creation time is the same, but the access and change time are still different for the files, using stat. For example:

on host

    File: `DSC00003.JPG'
    Size: 3068392    Blocks: 6016       IO Block: 32768  regular file     
  Device: 821h/2081d Inode: 2109        Links: 1
  Access: (0755/-rwxr-xr-x)  Uid: ( 1000/simona)   Gid: ( 1000/simona)
  Access: 2013-03-26 00:00:00.000000000 +0000 
  Modify: 2007-12-25 22:48:20.000000000 +0000
  Change: 2007-12-25 22:48:20.000000000 +0000

and on the destination

    File: `DSC00003.JPG'
    Size: 3068392    Blocks: 6008       IO Block: 4096   regular file
  Device: 802h/2050d Inode: 245762      Links: 1
  Access: (0755/-rwxr-xr-x)  Uid: ( 1000/simona)   Gid: ( 1000/simona)
  Access: 2013-03-26 10:24:49.000000000 +0000
  Modify: 2007-12-25 22:48:20.000000000 +0000
  Change: 2013-02-09 00:11:09.000000000 +0000

I don't want to copy the files again, this would be stupid, can you suggest a clean solution? How can I prevent this in the future? Is there a way to prevent rsync to overwrite pictures that have been modified more recently on the destination?

Upvotes: 3

Views: 2964

Answers (1)

nealmcb
nealmcb

Reputation: 13461

The underlying problem is that the camera is using Window's FAT file system, which is broken when it comes to time zones since it only stores local time. Endless problems ensue as different systems try to compensate for that breakage in different ways so as to avoid other kinds of breakage.

For one discussion, a solution for cygwin, and lots of references on the underlying problem, see Wayne Piekarski - Solution For Rsync and Cygwin Daylight Savings Timezone Problem

One of the references there has some of the specifics on the problem: Beating the Daylight Savings Time bug and getting correct file modification times - CodeProject

Those deal mostly with Windows, so I'm still working on how to cleanly deal with this on Linux. See e.g. Bug #25048 “Vfat filesystems don't respect timezone” : Bugs : “linux-source-2.6.15” package : Ubuntu

Some Linux solutions are discussed here: rsync and backup and changing timezone - Unix & Linux Stack Exchange, i.e. --size-only or --modify-window=3660, but they are risky since they will fail to make needed backups in some situations.

In my case the FAT file system is on an sdcard in an Android phone, which probably introduces yet more constraints on the possible solutions.

I would think this would be a pretty common problem, so I'm surprised that this isn't better documented.

Upvotes: 4

Related Questions