[jasode]

>What is your use case, if you don't mind sharing?

I have custom utilities that detects moved/renamed files by analyzing heuristics of filesize, modification times, and creation times. It can work with files' timestamps without any fractional seconds (nanoseconds) but the most reliable and confident heuristics takes advantage of nanoseconds to build the most accurate hashtable of files.

The latest rsync 3.4.4 will copy creation times but it didn't copy over the nanoseconds. It does copy the nanoseconds for file modification times but not the creation/birth times.

Command line file sync tools like rsync or robocopy can't detect file moves which means they will blindly delete files from the old spot and re-copy them to the new spot. Imagine a directory that's 2 terabytes full of files that were just renamed. Those utilities will delete 2 terabytes then recopy another 2 terabytes. It's a risk of losing 2 tb of files if there's a interruption and needless SSD wear & tear.

I may send my changes up to the rsync github repo. I just don't have an active account at the moment.

[adrian_b]

OK, you may be right.

I have always verified that rsync copies the modification timestamps with nanosecond resolution, because I use these timestamps, but I have never looked at the creation times, because I do not use them.

I always have content hashes attached to files in an extended attribute.

For detecting duplicates with different names I always use the content hash, which is much more reliable than a creation timestamp and it is also useful for other purposes, e.g. for detecting file corruption.