Bug: rsync erroneously changes modification time

[max.power--- via rsync]

When a file of same length already exists at the destination then the
command 'rsync --archive --size-only' (--archive is same as -rlptgoD)
may change the modification time of the destination file even if no
modification was made.

Type the following commands in a terminal in order to reproduce the problem:

$ mkdir source
$ mkdir target
$ echo "file one" > source/file
$ echo "file two" > target/file
$ srcstamp=201111110000.11
$ tgtstamp=200001010000.00
$ touch -t $srcstamp source/file
$ touch -t $tgtstamp target/file
$ stat -c "%y %s" source/file
$ stat -c "%y %s" target/file

Notice, that although the file in source/ and target/ folder contain
different content they do not differ in size. Thus, there following
command should not make any changes:

$ rsync -rlptgoD --size-only source/ target

There was indeed no backup performed, which can be verified by viewing
the contents of the files:

$ cat source/file
$ cat target/file

However, the modification time of the target file was updated to the
same modification time as file in source/:

$ stat -c "%y %s" source/file
$ stat -c "%y %s" target/file

Since the file was not modified the modification time should not be
changed. Omitting the '-t' option in above rsync does not solve the
problem because when a backup is actually performed then the
modification time will simply be set to the current system time
instead of the modification time of the source file.

The same behaviour can be observed when using the flags -rlptgoD (or
--archive) with the --checksum flag. Although it is highly unlikely
that the files will differ if the checksums are the same, the
modficaition should still not be changed for consistency reasons.




-------------------------------------------------

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!

[Kevin Korb via rsync]

Whenever you use --times (included in --archive) rsync will fix
incorrect time stamps. The only thing --size-only is doing is keeping
the incorrect data instead of replacing it.

The purpose of these options is to "fix" a copy done in a way that did
not preserve timestamps but the data is known to have not changed.
These options allow rsync to correct the incorrect timestamps without
even looking inside of the files. If you are not 100% sure your file
data matches you should not be using --size-only.

Post by max.power--- via rsync
When a file of same length already exists at the destination then the
command 'rsync --archive --size-only' (--archive is same as -rlptgoD)
may change the modification time of the destination file even if no
modification was made.
$ mkdir source
$ mkdir target
$ echo "file one" > source/file
$ echo "file two" > target/file
$ srcstamp=201111110000.11
$ tgtstamp=200001010000.00
$ touch -t $srcstamp source/file
$ touch -t $tgtstamp target/file
$ stat -c "%y %s" source/file
$ stat -c "%y %s" target/file
Notice, that although the file in source/ and target/ folder contain
different content they do not differ in size. Thus, there following
$ rsync -rlptgoD --size-only source/ target
There was indeed no backup performed, which can be verified by viewing
$ cat source/file
$ cat target/file
However, the modification time of the target file was updated to the
$ stat -c "%y %s" source/file
$ stat -c "%y %s" target/file
Since the file was not modified the modification time should not be
changed. Omitting the '-t' option in above rsync does not solve the
problem because when a backup is actually performed then the
modification time will simply be set to the current system time instead
of the modification time of the source file.
The same behaviour can be observed when using the flags -rlptgoD (or
--archive) with the --checksum flag. Although it is highly unlikely that
the files will differ if the checksums are the same, the modficaition
should still not be changed for consistency reasons.
-------------------------------------------------
ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No
bandwidth quotas!
Commercial and Bulk Mail Options!

[max.power--- via rsync]

How exactly does rsync determine that the copy has the incorrect
timestamp and not the source file?
Does it assume that the copy must be incorrect or are there other
criteria that have to be considered?

Post by Kevin Korb via rsync
Whenever you use --times (included in --archive) rsync will fix
incorrect time stamps. The only thing --size-only is doing is keeping
the incorrect data instead of replacing it.
The purpose of these options is to "fix" a copy done in a way that did
not preserve timestamps but the data is known to have not changed.
These options allow rsync to correct the incorrect timestamps without
even looking inside of the files. If you are not 100% sure your file
data matches you should not be using --size-only.

Post by max.power--- via rsync
When a file of same length already exists at the destination then the
command 'rsync --archive --size-only' (--archive is same as -rlptgoD)
may change the modification time of the destination file even if no
modification was made.
$ mkdir source
$ mkdir target
$ echo "file one" > source/file
$ echo "file two" > target/file
$ srcstamp=201111110000.11
$ tgtstamp=200001010000.00
$ touch -t $srcstamp source/file
$ touch -t $tgtstamp target/file
$ stat -c "%y %s" source/file
$ stat -c "%y %s" target/file
Notice, that although the file in source/ and target/ folder contain
different content they do not differ in size. Thus, there following
$ rsync -rlptgoD --size-only source/ target
There was indeed no backup performed, which can be verified by viewing
$ cat source/file
$ cat target/file
However, the modification time of the target file was updated to the
$ stat -c "%y %s" source/file
$ stat -c "%y %s" target/file
Since the file was not modified the modification time should not be
changed. Omitting the '-t' option in above rsync does not solve the
problem because when a backup is actually performed then the
modification time will simply be set to the current system time instead
of the modification time of the source file.
The same behaviour can be observed when using the flags -rlptgoD (or
--archive) with the --checksum flag. Although it is highly unlikely that
the files will differ if the checksums are the same, the modficaition
should still not be changed for consistency reasons.
-------------------------------------------------
ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No
bandwidth quotas!
Commercial and Bulk Mail Options!

--
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
Kevin Korb Phone: [phone]
Web page: http://www.sanitarium.net/
PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,

-------------------------------------------------

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!

[Fabian Cenedese via rsync]

Content-Transfer-Encoding: 7bit
Content-Disposition: inline
How exactly does rsync determine that the copy has the incorrect
timestamp and not the source file?
Does it assume that the copy must be incorrect or are there other
criteria that have to be considered?

rsync is only synching one way, it's always going from source to dest.
Therefore source is always 'correct' whereas dest will be adjusted to
match source. If you want a two way synching you'd need to call
rsync twice with different parameters (and switched source/dest)
or use a different tool.

bye Fabi

[Paul Slootman via rsync]

How exactly does rsync determine that the copy has the incorrect timestamp
and not the source file?

The source by definition is correct.


Paul

[max.power--- via rsync]

Ok, that clears things up.

Thanks.

Post by Paul Slootman via rsync

How exactly does rsync determine that the copy has the incorrect timestamp
and not the source file?

The source by definition is correct.
Paul
--
Please use reply-all for most replies to avoid omitting the mailing list.
https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

-------------------------------------------------

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!