Related to this question

Short description of the problem:

When source tree has a mounted point inside it, then time stamps on files inside that mounted point when copied to target tree are not preserved even when using -a option

Detailed description:

Assume this is the source tree:

                       /home/                           /home/
                         |                                |
                        me/                             BACKUP/
                         |                                |
                    +----+----------+                +----+-------+
                    |    |          |                |    |       |
                 data/  foo.txt    boo.txt         data/ foo.txt boo.txt
                    |                                |
                   a.txt                           a.txt

where data/ above is mounted external USB disk. Everything is ext4 file system. Everything in source is owned my me.

BACKUP also happened to be a mount point, the backup USB disk.

After issuing this command rsync -av --delete /home/me/ /home/BACKUP/, I found that /home/BACKUP/data/ and everything below it has the current time stamp, as if these files were created now, and not the time stamp on the files in /home/me/data/. Other files and folders outside data did have the time stamp preserved OK.

Question is: How to use rsync in the above setting to tell it to preserve time stamps on all files and folders even on files and folders on a mounted point?

I am using:

>uname -a
Linux 3.5.0-17-generic #28-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux

>rsync -v
rsync  version 3.0.9  protocol version 30

from man rsync:

   -t, --times                 preserve modification times

EDIT - to improve on this answer since it is not immediately obvious why this did not help OP:

OP is copying files from one filesystem to another and wanting to preserve c-time. Most people understand c-time to mean "create time" which is incorrect on most UNIX/Linux systems (Windows filesystems track "creation" or "birth" times).

For the most part, in UNIX and Linux, c-time is the timestamp used to record the last inode 'C'hange. An inode changes if any of its attributes are updated:

OP cannot preserve the c-time of their file's when they are brought onto a new filesystem. The creation of these files in the new filesystems is one of the conditions listed above (creation of inode/file).


  • 9
    Thank you. I know that. But please read the question again carefully. I did use -a which says: archive mode; equals -rlptgoD therefor -t is already included. – Nasser Jan 17 '13 at 7:11
  • 1
    are you trying to preserve change time? ctime is NOT for "created" its for (status) change – h3rrmiller Jan 17 '13 at 7:22
  • 1
    I want it to work just like it does on files that are not on the mounted disk. i.e. keep the same time stamp that one sees when doing ls -l on the file. This works on files that are not inside the mount point. But all files that are inside the mount point, have time stamp on them indicating they were just created. Whatever you call this time. I just wanted it to use the same time stamp on the files in the source. Now it does not. I want all time aspects be copied. i.e. a clone of the file be made. creation time, change time, etc... – Nasser Jan 17 '13 at 7:31
  • 5
    the change time (ctime) gets updated upon a change to the inode (ie. creation/permission change/moving/etc). because you are creating a new inode (because you are copying the file accross a filesystem (separate inode tables) the ctime is updated. there is no way around that because it is the change of the inode, not the file. take a look at en.wikipedia.org/wiki/Stat_(system_call)#ctime – h3rrmiller Jan 17 '13 at 8:01
  • 3
    ls -l shows mtime (modify) not ctime – h3rrmiller Jan 17 '13 at 8:03

as hr3miller already said, -a (or --archive) is equal to -rlptgoD and already includes syncing time.

However when rsync copies data to, eg. an NFS/FAT32/NTFS mount where preserving user and owner fails, rsync won't try to set the time. Rsync will warn with something like

rsync: chown "/mnt/backup/postgres/hourly.0/primary/var" failed: Operation not permitted (1)

Therefore leave out preserving user and group by using


instead of


Only use this when not preserving the owner and group is an option for you. Note that preserving symlinks and other features could trigger that behavior, too. You will have to go through the man page for every rsync feature (-r -l -p -t -g -o -D) you want to backup.


You can use the touch tool for that. The -r argument will copy the timestamps from one file / folder to another.

cd srcParentDir
find srcDir -exec touch -r {} /target/dir/{} \;

Or for your example:

cd /home/me
find . -exec touch -r {} /home/BACKUP/{} \;

which will execute the following statements:

touch -r ./data/a.txt /home/BACKUP/./data/a.txt
touch -r ./foo.txt /home/BACKUP/./foo.txt
touch -r ./boo.txt /home/BACKUP/./boo.txt

And thus basically copy the old timestamps to the new filesystem.

If you have spaces in the destination path you have to escape them /home/my\ spaced\ path/. I think {} will do the escaping for you, though I am not 100% sure.


I use rsync -az and sure thing it preserves me the modification time. I double-checked it right now.

  • 2
    That's because -a (--archive) includes -t. – heemayl Oct 17 '16 at 6:13
  • However no, ctime cannot be arbitrarily reset. (I misunderstood the quesiton originally, sorry.) – Mik Oct 17 '16 at 6:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.