Rsync : copying over timestamps only

41,476

Solution 1

Using -t (preserve timestamps) and --size-only will only compare files on size. If the size matches, rsync will not copy the file but since -t is specified, it will update the timestamp on the destination file without recopying it.

Make sure to not use -u (update) as this will skip files that already exist and completely skip updating the timestamp.

I had the problem of originally not using rsync to copy a bunch of files to a new drive, and therefore the timestamps were updated to current time. I used the command below to sync everything correctly in a decent amount of time:

rsync -vrt --size-only /src /dest

Solution 2

Using --size-only will cause rsync to skip comparing file timestamps (and therefore file contents) if the sizes match. Combining this with --times will clone the timestamps across to the target tree.

Solution 3

I think rsync is the right tool to make this but if you want some script to do this than someting this can give a good start.

You can get a file list with timestamps (acces times) like this:

find . -printf '"%p" %a\n' -type f > /tmp/times

And get the appropriate time update commands from it:

 while read line; do echo touch -a -d \"${line#* }\" ${line%% *}; done < /tmp/times

It isn't a complete script but a good start place!:)

Solution 4

Use the source (e.g. /path/to/source) directory as reference for the touch command. Just cd to your target directory and do

find -type f -exec touch -r /path/to/source/{} {} \;

You cannot copy sub-second timestamps with rsync (yet).

This also works for directories and pseudo files (just remove or change the -type f)

Solution 5

Well, you could certainly write a script that reads the timestamp from one side and then uses touch to set it on same file on the other side.

But that would likely take you much longer than simply letting rsync try to copy all the files. Very little data will actually be transferred (only block hashes if the files are truly identical). But the full contents of every file will have to be read on each side at the least. So of you are limited by disk bandwidth or IOPS it could take a while. But still probably less time than writing and testing a script to do it.

Share:
41,476

Related videos on Youtube

artella
Author by

artella

Updated on September 18, 2022

Comments

  • artella
    artella over 1 year

    Currently I have two directories A/ and B/ which are identical in every respect, with the exception of the timestamps. Therefore if I run the command :

    rsync --dry-run -crvv A/ B/
    

    then all files are marked "uptodate", whereas the command :

    rsync --dry-run -rvv A/ B/
    

    shows that all files are to be copied over from A/ to B/.

    My question is this : given that I know the files are identical (in respect to contents), then is there any way (via rsync or otherwise) to set the timestamps for files in B/ to be identical to the timestamps of the files in A/, without copying over all the files from A/ to B/ ?

    Thanks

    • Tim
      Tim over 12 years
      If you know the files are identical, then why must you go out of your way to not copy over them to get the date/time stamp you require?
    • Richard
      Richard almost 8 years
      @Tim: maybe there's a lot of data.
    • 比尔盖子
      比尔盖子 over 3 years
      @Tim Today I just spent an entire day migrating over 300 GB of data over a slow network. When sftp finished, it was already midnight. It was only during my final check using ls and stat that I realized I lost all the timestamps (forgot to use sftp -p!) They are important for me to identify the history of the files. I was saved by the answer, rsync -vrt --size-only only took 60 seconds to run!
  • artella
    artella over 12 years
    Thanks, I was unaware of this feature of rsync (it is discussed in wikipedia too).
  • artella
    artella over 12 years
    Thanks. I think I will probably stick with Rsync for the moment, but I will definitely go out to the web and learn the different components of your script, as it may be useful in the future.
  • leden
    leden about 8 years
    I also suggest adding --existing to prevent accidental copies of new files.
  • Burcardo
    Burcardo almost 8 years
    That seemed to be exactly my solution! I want to preserve the times while adding some meta data to my music library. However, apparently it can't handle spaces in file names ):
  • Dor
    Dor about 7 years
    The flag --archive (or -a) includes -r, -t and more :)
  • hagello
    hagello about 6 years
    To avoid (some) problems with backslashes in your file names, use read -r line. Well, always use read with -r. Besides, you can avoid opening job.sh for each file. Just put the redirection at the end of the command: while read -r path; do echo touch -a -d $path ; done < /tmp/times > job.sh
  • hagello
    hagello about 6 years
    2nd Caveat: This script does not transfer the timestamps the directories. (Well, the OP did not ask for it.)
  • snapfractalpop
    snapfractalpop about 6 years
    This was useful for me as I needed atime to be copied. I noticed it does not copy ctime, which was ok in my case.
  • knorke
    knorke about 6 years
    Just read the manpage of 'touch'. You can set atime and mtime both with this command.
  • snapfractalpop
    snapfractalpop about 6 years
    Yes, I know you can use touch -ar but that still does not change the ctime. I suppose that's rarely desired.
  • knorke
    knorke about 6 years
    Ah, I see the problem now. Thanks. Yes, ctime is hard to change and I don't know why.
  • troseman
    troseman over 3 years
    prefer this answer since rsync works over remotes also
  • 比尔盖子
    比尔盖子 over 3 years
    @TomHale -N (--crtimes) indeed exists, but only in newer versions of rsync. But yeah, it's almost useless for this scenario - it means "preserve create times (newness)" - as far as I know, "file create time" is never implemented by most Unix file systems, ext4 was the only major file system that included it in the specification, but still, is never actually implemented in the Linux kernel.
  • user1602
    user1602 over 2 years
    Adding --checksum on top of that should take care of files with the same size but different contents.