mtime vs ctime
kmk at sanitarium.net
Tue Sep 8 03:21:15 UTC 2015
-----BEGIN PGP SIGNED MESSAGE-----
I would need to see both your existing rsync command line and the
output of --itemize-changes when such an occurrence happens before I
can really understand what is happening.
In the end, if you have any output at all the bare minimum should be
- --itemize-changes. --verbose is utterly useless without it.
On 09/07/2015 11:10 PM, Andrej wrote:
> On 8 September 2015 at 13:57, Kevin Korb <kmk at sanitarium.net>
> wrote: Hi Kevin.
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> The ctime will always be newer or the same as the mtime. This
>> is because changing the mtime also changes the ctime as does
>> other things like changing the permissions.
>> Rsync only pays attention to the mtime because rsync can set a
>> specific mtime (--times) but setting a specific ctime is
>> impossible as it would violate the basic *nix security model.
>> Therefore ctime can't be copied, therefore ctime can't ever be
>> expected to match, therefore it is useless to rsync.
> If this is the case I don't understand the behaviour I'm seeing
> here. The files mtime haven't changed, the time-stamps of the
> copies on the backup server and the time-stamp on the iSCSI mount
> are the same (the mtime, that is; the ctimes differ, obviously, as
> all files have the time-stamp of the mount-event).
> Do you have an explanation?
>> Rsync should be using the delta transfer algorithm (unless -
>> --whole-file) so it really should just be determining what is
>> different about the file then transferring those differences.
>> --stats would help determine this.
> Hmmmm ...
> Doesn't look like it to me.
Kevin Korb Phone: (407) 252-6853
Systems Administrator Internet:
FutureQuest, Inc. Kevin at FutureQuest.net (work)
Orlando, Florida kmk at sanitarium.net (personal)
Web page: http://www.sanitarium.net/
PGP public key available on web site.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
More information about the rsync