mtime vs ctime

Kevin Korb kmk at
Tue Sep 8 03:21:15 UTC 2015

Hash: SHA1

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>
> wrote: Hi Kevin.
>> 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  (work)
	Orlando, Florida		kmk at (personal)
	Web page:
	PGP public key available on web site.
- -*~
Version: GnuPG v2


More information about the rsync mailing list