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