https://bugzilla.samba.org/show_bug.cgi?id=13222
Wayne Davison <way...@samba.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #2 from Wayne Davison <way...@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 -@-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.
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
