Hi. Like many people, I am using rsync with --link-dest to create hard- linked efficient backups. I've run into the infamous 65K directory entry limit of ext4 however and am getting the following error from rsync: rsync: link "/.snapshots/daily.0/pc/usr/src/kernels/7.0.8-200.fc44.x86_64/include/config/ACPI_SBS" => usr/src/kernels/7.0.8-200.fc44.x86_64/include/config/64BIT failed: Too many links (31) File-list index 3 not in 1358033 - 1366147 (finish_hard_link) [generator] rsync error: protocol incompatibility (code 2) at rsync.c(746) [generator=3.1.3] rsync error: received SIGUSR1 (code 19) at main.c(1445) [receiver=3.1.3] and it exits with an exit code of 2. It seems to me that in such a case, a(n option to) fall-back to just creating a new (albeit inefficient) copy of the file would be the most data-safe path to take. Perhaps with a warning of some sorts. In researching, I came across [#329](https://github.com/RsyncProject/rsync/issues/329) where the OP reports: ext4 supports a maximum number of 65000 hard links per inode. When this is exceeded and rsync tries to create another hard link, it falls back to copy. But clearly I am not experiencing that fall-back to copy. Have I run into some kind of bug with that feature here? Or does that feature not actually exist and the info in #329 is either simply inaccurate or perhaps out of date with current behavior? FWIW, I am using rsync version 3.4.1 on the source (where the file is being copied from) and 3.1.3 on the destination (where the file is being copied to and where the rsync command is being driven). Thoughts? b.