rsync - Jan 2018 - [Bug 13222] New: rsync creates warning if time of destination file differs in fractional part of second and owner mismatches

https://bugzilla.samba.org/show_bug.cgi?id=13222

            Bug ID: 13222
           Summary: rsync creates warning if time of destination file
                    differs in fractional part of second and owner
                    mismatches
           Product: rsync
           Version: 3.1.2
          Hardware: x86
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: core
          Assignee: wayned at samba.org
          Reporter: mueller at relog.ch
        QA Contact: rsync-qa at samba.org

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 at 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 at 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 at 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 at trotsig:~> touch aa

# copy under second user now succeeds
cron at trotsig:/home/mueller> rsync -a aa invik:/home/mueller
cron at trotsig:/home/mueller>

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=13222

--- Comment #1 from Urban Mueller <mueller at relog.ch> ---
in the short description, I meant to say "chmod" not
"chown", sorry.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=13222

Wayne Davison <wayned at samba.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #2 from Wayne Davison <wayned at samba.org> ---
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 - at -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).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=13222

--- Comment #3 from Urban Mueller <mueller at relog.ch> ---
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?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.