Public bug reported: Rsync in Ubuntu 20.10 fails when /proc isn't mounted, while it worked before. This happens because AC_CHECK_FUNC(lchmod) returns "yes" in 20.10, while it returned "no" before.
Steps to reproduce: # Emulate /proc not being mounted $ mount --bind / /mnt $ chroot /mnt rsync -a /bin/ls . rsync: [receiver] failed to set permissions on "/.ls.CDExhu": Operation not supported (95) rsync error: some files/attrs were not transferred (see previous errors) (code 3) at main.c(1330) [sender=3.2.3] I reported this issue upstream in https://github.com/WayneD/rsync/issues/109 but the rsync developer says it's a problem in libc, and it might well be. Simple C code to reproduce the problem without rsync: printf("lchmod returned: %d\n", lchmod("/tmp/ls", 0755)); If /tmp/ls is e.g. mode=0123, and needs to be changed, lchmod fails when /proc isn't mounted, yet it succeeds if it is mounted. Python had a similar issue, and they ended up avoiding AC_CHECK_FUNC(lchmod) under Linux: https://bugs.python.org/issue34652 https://github.com/python/cpython/commit/69e96910153219b0b15a18323b917bd74336d229#diff-49473dca262eeab3b4a43002adb08b4db31020d190caaad1594b47f1d5daa810R3140 ```c if test "$MACHDEP" != linux; then AC_CHECK_FUNC(lchmod) fi ``` So I'm not sure which package is causing the bug here. Should autoconf return false? Should libc implement lchown without the bug? Or should rsync skip lchmod under Linux, like python did? ** Affects: rsync (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsync in Ubuntu. https://bugs.launchpad.net/bugs/1902109 Title: rsync uses lchmod and fails in Ubuntu >= 20.10 Status in rsync package in Ubuntu: New Bug description: Rsync in Ubuntu 20.10 fails when /proc isn't mounted, while it worked before. This happens because AC_CHECK_FUNC(lchmod) returns "yes" in 20.10, while it returned "no" before. Steps to reproduce: # Emulate /proc not being mounted $ mount --bind / /mnt $ chroot /mnt rsync -a /bin/ls . rsync: [receiver] failed to set permissions on "/.ls.CDExhu": Operation not supported (95) rsync error: some files/attrs were not transferred (see previous errors) (code 3) at main.c(1330) [sender=3.2.3] I reported this issue upstream in https://github.com/WayneD/rsync/issues/109 but the rsync developer says it's a problem in libc, and it might well be. Simple C code to reproduce the problem without rsync: printf("lchmod returned: %d\n", lchmod("/tmp/ls", 0755)); If /tmp/ls is e.g. mode=0123, and needs to be changed, lchmod fails when /proc isn't mounted, yet it succeeds if it is mounted. Python had a similar issue, and they ended up avoiding AC_CHECK_FUNC(lchmod) under Linux: https://bugs.python.org/issue34652 https://github.com/python/cpython/commit/69e96910153219b0b15a18323b917bd74336d229#diff-49473dca262eeab3b4a43002adb08b4db31020d190caaad1594b47f1d5daa810R3140 ```c if test "$MACHDEP" != linux; then AC_CHECK_FUNC(lchmod) fi ``` So I'm not sure which package is causing the bug here. Should autoconf return false? Should libc implement lchown without the bug? Or should rsync skip lchmod under Linux, like python did? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1902109/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
