These variants have lower overhead than their path-taking counterparts. This makes compressing the github dataset something like 10% faster, recovering much of the regression introduced in the 3 added syscalls of #3432.

Note that this requires making some changes to the flow of these syscalls. Previously, we close()-ed the file, then utime()-ed it, then ch{mod,own}()-ed it. However, an fd is only valid while the file is open, so in order to call fchmod() and fchown(), we need to move those calls to before we close() the file. While there is also a futimens(), we can't use it, since the utime() call has to come after we close() the file, so that we end up with the desired atime. (If we utime() then close(), the close() will override the atime we set.) So the new order is fch{mod,own}(), close(), utime(). This raises minor questions about whether this will now produce situations where we chown() the file away in such a way that we then don't have permissions to utime() it. But I think those concerns are unfounded. man utimensat says we need:

2. the caller's effective user ID must match the owner of the file; or
3. the caller must have appropriate privileges.

But we can only chown() the file away to a different uid if:

Only a privileged process (Linux: one with the CAP_CHOWN capability) may change the owner of a file.

So I think it's unlikely there are situations where we can chown() something away to a state where we can't then utime() it.