Thank you both! I think I have figured out how to reliably reproduce it now. I think there are actually two different bugs:
--copy-linksis erroneously behaving like--links, unless--local-no-cloneis used.
In other words, the dst ends up with a link instead of a regular file. (Can you confirm whether you are seeing this too?)
- Creating a link to a relative path in the dst fails if the file it's pointing to doesn't exist yet.
I think I wasn't seeing this at first because I tried with an absolute path instead of relative.
I was also confused at first because whether a link is created before its target is subject to the whims of concurrency and ordering. So, in the above example where file comes before link alphabetically, I found that to make it deterministically fail I had to add:
--check-first --order-by name,desc --transfers 1
and to make it deterministically succeed I had to change desc to asc.
This would also explain why it fails but then succeeds on retry (which also confused me.)
Now that I think I know why it's happening I think I should be able to fix it. One thing I guess I'm not sure about is how we normally handle the scenario where we want to create a relative link in the dest to another dest file that doesn't exist yet -- I guess we probably just don't check whether it exists, and create it regardless?
Does that all generally sound right to you?