4

There are many questions online asking how to make the commands rsync and cp go about copying a file while keeping the "date created" attribute the same as the original instead of the time of copy. I understand this is Mac's added information and is separate from the file's metadata "date created" attribute. Anyways, as I played around with rsync -a, it did everything I wanted except, as everyone online notes, it changed the "date created" to the time of copy instead of original make. With rsync and cp it changes due to "a change to the inode". Command-c command-v, however, keeps the "date created" time the same.

Here's my question: How is it that Cmd-C Cmd-V keeps the date created attribute the same on the copy, yet no command in the terminal will yield this result? If Cmd-C Cmd-V can do it, it seems there has to be some command in the Terminal that replicates this?

  • Where did you verify whether the dates change or stay the same, in Terminal or in Finder? As can be easily verified using stat -s, even Cmd-C/Cmd-V changes ctime and ctime information, so which timestamps do you want to stay the same here? – nohillside Aug 10 '15 at 6:45
  • If XCode is installed Getfilinfo file returns the file info. See developer.apple.com/library/mac/documentation/Darwin/Reference/… – Scott Porter Aug 10 '15 at 6:54
  • 1
    'NIX does not have a "date created" attribute (unlike Windows). st_ctime in the struct stat actually records the last time the inode changed. OS X 64 bit has st_birthtimespec; /* time of file creation(birth) */ but accessing this is not straightforward. – Milliways Aug 10 '15 at 12:27
  • Patrix: is there a way to view "stat -s <name of file>" with yyyy/mm/dd format for each date returned? And I am trying to get Finder's "created" date to stay the same. – Adam Aug 10 '15 at 14:05
  • Scott and Milliways, thank you, I do not have much time right now, I'll check your answers later today. – Adam Aug 10 '15 at 14:06
2

As stated POSIX does not define "date created" and command line tools are written to POSIX standards but may extend the standards. The behavior of rsync and cp are what is expected. Some file systems and kernels extend the standards and include birthtime or btime.

Assuming you are copying files to the same file system then OS X has tools that will attempt to preserve birthtime ("date created"). You could use pax or hardlink files and the "date created" will be preserved. Less reliable tools are ditto or cp with the p option (at least on my system, I suspect bugs in HFS+).

If you want to copy files to another file system then you need to compile rsync with the patches fileflags, crtimes, hfs-compression and rsync can handle OS X metadata and preserve the original file's birthtime on the new file.

  • Ok, you're right, when copying files from one location on my mac to another, rsync keeps the "date created" the same. I forgot to mention that I'm copying files from my mac to a Seagate hard drive. This is where command-c command-v keeps the "date created" the same yet rsync -av does not. – Adam Aug 11 '15 at 5:44
2

On 10.10.4, using cp -p /path/to/source /path/to/destination the time created is preserved. More specifically, in Finder, date created and date modified are preserved, while date added will have the copy time.

2

There are many reasons why one would rather use RSync instead of cp. RSync's default version on MacOS is 2.6.9, which is more than 12 years old as of today, and has several known bugs, and this is one of them. Apple won't include the updated versions on the new releases of the Mac OSX because of GPL3-related stuff.

To address this issue:

  1. Install homebrew in your Mac, if you don't have it already

    /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

  2. Install the new version of rsync available on brew:

    brew install rsync

  3. Certify that your rsync version is at least 3.1.3:

    fabiosl@macpro ~ $ rsync --version

  4. Copy your files using the --times and --crtimes

    rsync -times --crtimes /sourcedirectory /destinationdirectory

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .