Bug 13222 - rsync creates warning if time of destination file differs in fractional part of second and owner mismatches
Summary: rsync creates warning if time of destination file differs in fractional part ...
Status: RESOLVED FIXED
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.2
Hardware: x86 Linux
: P5 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-15 15:35 UTC by Urban Mueller
Modified: 2018-01-16 11:40 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Urban Mueller 2018-01-15 15:35:16 UTC
reproduction:
1. create file on machine A and chown it to 666
2. create file on machine B with slightly different timestamp (within same second) and chown it to 666
3. under different user (who can write the directory), rsync -a this file from machine A to B

expected:
file on B now has the same timestamp as file on A. (worked using rsync 3.1.0, also works if time difference is more than one second)

results:
file on B retains different timestamp and error is generated


more detailed:

# create files
mueller@trotsig:~> ssh invik 'rm -f aa; touch aa; chmod 666 aa; ls -l --full-time aa'; rm -f aa; touch aa; chmod 666 aa; ls -l --full-time aa
-rw-rw-rw- 1 mueller trusted 0 2018-01-15 16:25:03.299655606 +0100 aa
-rw-rw-rw- 1 mueller trusted 0 2018-01-15 16:25:03.310296840 +0100 aa

# try to copy files under different user
cron@trotsig:/home/mueller> rsync -a aa invik:/home/mueller
rsync: failed to set times on "/home/mueller/aa": Operation not permitted (1)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1178) [sender=3.1.2]

# timestamp still wrong
cron@trotsig:/home/mueller> ls -l --full-time /home/mueller/aa; ssh invik ls -l --full-time /home/mueller/aa
-rw-rw-rw- 1 mueller trusted 0 2018-01-15 16:29:50.087861989 +0100 /home/mueller/aa
-rw-rw-rw- 1 mueller trusted 0 2018-01-15 16:29:50.079375446 +0100 /home/mueller/aa

# first user touches file for bigger time delta
mueller@trotsig:~> touch aa

# copy under second user now succeeds
cron@trotsig:/home/mueller> rsync -a aa invik:/home/mueller
cron@trotsig:/home/mueller>
Comment 1 Urban Mueller 2018-01-15 16:16:46 UTC
in the short description, I meant to say "chmod" not "chown", sorry.
Comment 2 Wayne Davison 2018-01-15 19:08:58 UTC
This is something that changed in 3.1.2 -- rsync used to leave the nano-seconds unchanged if they differ as long as the integer seconds were the same. In 3.1.2, it started to force the nanoseconds to match when -t was specified. Since you have to be the owner of the file to set its time, the OS throws an error trying to fix the nanoseconds on the otherwise unchanged file.

In thinking about this a bit more, I believe that forcing the nanoseconds to match is not ALWAYS the right thing to do. It is desired if the file was transferred or if --checksum was used (since we're sure that the files are the same), but if just the quick-check verified that the files were identical (and that check didn't compare the nanoseconds), leaving the nano-seconds different will preserve a potential difference indicator that a future transfer could use to make sure that the files were really identical (e.g. the new -@-1 (--modify-window=-1) option in 3.1.3).

I'm improving this code in 3.1.3 so that we only fix the microseconds on a file with identical int seconds if there is an extra reason to do so. (This change is not in 3.1.3pre1, but currently only on the master branch.)  This avoids the outputting of an error in the situation you describe (working just like 3.1.0), but if you added the -c (--checksum) option, it would complain about being unable to set the timestamp (and rightly so).
Comment 3 Urban Mueller 2018-01-16 11:40:47 UTC
Thanks for the fix, that will solve my problem. However I think the planned -c behaviour is surprising in a bad way. If rsync has a way to achieve its desired target state, IMHO it should. Example: If the target directory is writable but contains a file owned by root with mode 600 (ie not writable by normal users), rsync -ac will happily replace it if a normal user transfers a file with the same name. However if the file has a nearly identical time stamp and is otherwise identical with the source, he suddenly gets a warning every time he tries to copy?