rsync and date modified

[Essence_of_War]

I have a backup script that does the following:

1) It creates a new target folder with the current date on an ext4 filesystem.
2) It finds the previous folder (also on the ext4 filesystem) to use as a hardlink reference.
3) It rsyncs from an NTFS source to the target, hardlinking against the reference.

I've noticed that the date modified attribute after the rsync job finishes is ALWAYS wrong. It's not hard to fix this, I can pre-create the folder with mkdir, or touch the folder after rsync creates it, and I've tested both ways and it works fine. I'm just confused as to why when rsync creates the folder, it doesn't seem to get the date modified attribute correctly.

I'm running effectively the same script on two machines, one running ubuntu 14.04, one running 12.04, both have the problem, and I'm using the -avh flags for rsync.

 

[KillerBee]

How far off is the mtime - is it same difference after every run?
Are all the clocks synced between source and dest?

 

[Essence_of_War]

Are all the clocks synced between source and dest?

The source and dest are both direct-attached storage, to the same platform. So I assume that means the clocks are sync'd?

How far off is the mtime - is it same difference after every run?

Pretty far, it looks like for the last several back-ups (two in November, two in october, 1 in december) all show up w/ modification time of June 19th.

 

[KillerBee]

what is the date of the src directories?

using rsync "-a" is same as using rsync "-rlptgoD"
where the -t preserves the modification times

 

[Essence_of_War]

Ah, a good question.

The date modified for the source folder is indeed reported as June 19th. But there are a ton of folders and files inside of that that have been created more recently than June 19th. Is this a problem with how NTFS reports properties/attributes through FUSE to Linux?

 

[KillerBee]

It's the way it's supposed to work when using the "-a" option

If you really really really need all the new dirs and files to have the same modification time as when the rsync was done vs the mod times of the original files I guess you could use rsync -rlpgoDvh

ie: drop the -t flag

though not sure why you would want to?

 

[Essence_of_War]

Thanks for being so patient with me, I'm pretty embarrassed, I think the source of my confusion was that I wasn't correctly understanding when mtime for a directory is updated, that is to say, ONLY when itself, a subdirectory, or file is modified, not a sub-sub-directory (or lower) or a file in a sub directory.

Sorry to waste your time, and thanks for talking me through this!

 

[KillerBee]

ahh I see now - glad to hear you got it all sorted 😀

 

[Essence_of_War]

Yeah, I thought that if rsync created the target directory, it would also give that directory's mtime as the time it was created, but (of course), since I was using the 'a' flag, it copies over the mtime of the source directory.

This has actually been really good, I clarified my understanding of something, and I re-wrote part of my backup scripts to make everything consistent, and not accidentally do something silly when they're finding their hardlink target 🙂