Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have two file trees. The first one consist of original files. The second one is a duplicate but lacking correct file timestamps, they are all set to the last duplication date.

Is there a clean and easy way to copy the file timestamps from one tree to another, without transferring the files contents again?

Add on: The two trees may differ slightly in some files, as the duplicate where made at some point in the past. The timestamps should just be updated when possible.

share|improve this question
add comment

3 Answers

up vote 2 down vote accepted

You could try with:

cd /path/to/old/directory

find . -exec touch "/path/to/new/directory/{}" --reference "{}" \;

touch --reference someotherfile changes the date and time of a file by using someotherfile as reference.

If the trees are identical, then the {} part will be expanded to the same file in both trees, and the new directory prefix will do the rest. You can use echo instead of touch to verify that the correct files are being walked.

Of course this executes a touch process for every file. Possibly a Python script would work more efficiently.

share|improve this answer
    
This works well, except it is a little slow as you stated. Suprisingly, it does makes several hundred files per second, which is quite cool if you remember a new touch is run for every file.. however, I will try a Python script like you propose. –  dronus Aug 25 '13 at 14:55
add comment

Try using rsync and its --size-only option.

rsync -avi --size-only A/ B/

This should only check the files' sizes and update the timestamps.

share|improve this answer
    
On some systems, the timestamps might only look identical, but have a sub-second drift (you can check with ls --full-time), since the timestamp set by rsync is exact at the seconds level (i.e. 12:34:45.0000) while the filesystem might set it at the microseconds level). In such cases, a second rsync in the opposite direction might be required. –  lserni Aug 25 '13 at 13:08
    
Looks cool. I also added --existing to prevent rsync copying files again that where deleted after the duplication. –  dronus Aug 25 '13 at 13:23
    
Even when using --existing, there is still some risk loosing modifications made to some files since the duplication. Maybe there is some way preventing rsync from copying content at all? Then the problem would shrink to some resetted timestamps. On the other hand, using rsync without --size-only would give a precise picture of what files would need a new timestamp and which do not. Using with -n for dry run, I would get a list stating >f for files that would be reseted but should not, and .f.t for files that are old and would get the correct old timestamp. But how to apply it then? –  dronus Aug 25 '13 at 13:32
    
That seems to be a dead end. rsync works well if the trees are identical except the timestamps, but if there are any other changes, it gets too complicated to keep rsync from applying them either. –  dronus Aug 25 '13 at 14:56
add comment

A short python script will do:

#!/usr/bin/python

import os
import sys

for directory,subdirs,files in os.walk('.'):
    pathes=subdirs+files
    for path in pathes:
        fullpath=os.path.join(directory,path)
        target_path=os.path.join(sys.argv[1],fullpath)
        mtime=os.lstat(fullpath).st_mtime
        print 'touching',target_path,':',
        try:
            os.utime(target_path,(mtime,mtime))
            print 'OK'
        except:
            print 'FAILED'

it has to be run in the source dir, given the target dir as the only argument, eg.:

python ~/sync_tstamps.py /path/to/target_dir

share|improve this answer
add comment

Your Answer

 
discard

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.