Fixes for https://sourceware.org/bugzilla/show_bug.cgi?id=14578 introduced regressions in cases when /proc is not mounted: - lchmod used to return ENOSYS, now it returns EOPNOTSUPP; - fchmodat(AT_SYMLINK_NOFOLLOW) used to return ENOTSUP, now it returns EOPNOTSUPP which is different from ENOTSUP on some architectures, e.g. hppa.
Hello, just noting that rsync in Ubuntu 20.10 is affected by this glibc issue: https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1902109 https://github.com/WayneD/rsync/issues/109
Also rsync in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1894485
I think there is no much glibc can do without proper kernel support [1]. [1] https://sourceware.org/pipermail/libc-alpha/2020-July/116513.html
Just letting you know that we reverted commit 6b89c385d8bd0700b25bac2c2d0bebe68d5cc05d in our glibc build shortly after reporting this issue.
(In reply to Dmitry V. Levin from comment #4) > Just letting you know that we reverted commit > 6b89c385d8bd0700b25bac2c2d0bebe68d5cc05d in our glibc build shortly after > reporting this issue. Reading rsync bug report, I really think that EOPNOTSUPP is the correct error code to return in this case. The configure was done on a build system where lchmod does work (since it has procps mounted). So I do not fully agree this really characterizes as a regression. And I don't think reverting lchmod support since propcs might be not available is the correct approach, best option would try to ask kernel to have proper syscall support which does not require userland hacks. Rick Felker already sent a patch, but it seems to be stuck.