Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I recently bought new hard drives for my NAS. This means that I'm copying all the data off the NAS, upgrading it, and then moving the data back.

I've gotten as far as copying the data from the NAS, but every file's modified/created date has been changed to when it was copied (today).

Is there a way, keeping in mind that I have the original data, to batch update the modified/created dates on the copied files without having to copy them over again (we're talking over a terabyte of data)?

share|improve this question
up vote 1 down vote accepted

touch can change the access and modify times. Try something like (untested):

find /path/to/source_files -exec touch --reference={} /path/to/dest/{} \;

This could work if the destination path (copied files) is named as a superset of the path of their original location. If the relationship is more complicated, you will need to do some manipulation of the paths.

Regarding the ctime, this is from info touch:

Although 'touch' provides options for changing two of the times--the times of last access and modification--of a file, there is actually a third one as well: the inode change time. This is often referred to as a file's 'ctime'. The inode change time represents the time when the file's meta-information last changed. One common example of this is when the permissions of a file change. Changing the permissions doesn't access the file, so the atime doesn't change, nor does it modify the file, so the mtime doesn't change. Yet, something about the file itself has changed, and this must be noted somewhere. This is the job of the ctime field. This is necessary, so that, for example, a backup program can make a fresh copy of the file, including the new permissions value. Another operation that modifies a file's ctime without affecting the others is renaming. In any case, it is not possible, in normal operations, for a user to change the ctime field to a user-specified value.

share|improve this answer
This works perfectly like you said, when the destination path is named as a superset of the original path. I set up some test data laid out as such and it works brilliantly. Now, I would like to execute this on the real thing - except that the source and destination files are both smb:// paths. How exactly would I do the path manipulation? – Billiam Dec 30 '10 at 19:55
@Billiam: Can you smbmount them into mount points in your host? – Dennis Williamson Dec 30 '10 at 20:03
Alrighty. Thanks for all the advice. Mounted the drives, and used a little bash script to manipulate the path so as to avoid the superset problem. Worked like a charm! – Billiam Dec 31 '10 at 18:07

How are you coping the files?

The *nix cp command has the parameter -p to preserve the time stamp. Perhaps you have something similar on your system.

share|improve this answer
That's the thing. The copy's been done, I already messed up, and I'm looking for a way to fix my mistake without re-copying all the data. – Billiam Dec 29 '10 at 7:00
Then it is even more important to know the system you are using. – Christian Dec 29 '10 at 9:51

If you are using Windows, you might try xxcopy (has an evaluation period). Specifically, this switch looks useful:

/TCC  Copies the timestamp of Create Time fm src to dst.

(have not tried this myself, but have use this program many times before)

share|improve this answer

On *nix i would suggest to use rsync.

There is DeltaCopy for Windows, but i've never tried that. Probably, there are others.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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