On 2025-09-13 06:44, Kye Hunter wrote:
1. The one that is more inconvenient for me is that at the end of the process, cp rewrites the permission bits on the target directory, even when they match the current permission bits (line 93 of the trace).
Yes. Unfortunately it's more complicated than the mode, as the Linux xattr library don't give 'cp' an easy way to test whether the extended attributes are identical. We could add this to our list of things to do but any changes along these lines would be nontrivial.
2. The other odd thing in the trace is that there are some kind of odd shenanigans going on with the two identical binary files, and a third temporary file that cp makes and then removes. I don't really follow the logic of the series of "linkat"s, "renameat"s, and "unlinkat"s around lines 70-80 of the trace, but while I could accept that they're somehow useful, what definitely seems like a bug is the message printed (due to being in verbose mode) at line 98 of the trace. The message makes the claim that a certain file in the target directory was removed, but it's definitely still present
It was removed, and replaced by a hard link to another file in the destination, presumably so that the pattern of hard links in the destination is identical to that in the source.
The linkat dance is merely to make sure that the destination always exists; there is never even the tiniest window during which the destination is temporarily absent while cp is running.
the trace doesn't show any equivalent writes to the target directory, only the ones in the source directory
I see only writes to the target directory.
