> Do you have a recipe, preferrably a shell script example that shows > this?
I do not have a small, reduced repro, as I'm not sure what is triggering the failed fchownat call in cp, which sets up errno to trigger the bug. What I got managed to reduce down to follows, but the tarball is large (~500 MB). That said, the patch you sent fixes this bug for me #!/bin/sh set -ue wget -nc https://github.com/riscv-collab/riscv-gnu-toolchain/releases/download/2026.05.06/riscv64-musl-ubuntu-24.04-gcc.tar.xz tar -xvf riscv64-musl-ubuntu-24.04-gcc.tar.xz find riscv -exec setfattr --name=user.test --value="test" {} \; mkdir -p pkg fakeroot cp -pR ./riscv/* ./pkg/ > >>I'd also like to note that it's *not* legal for syscalls to clear > >>errno, which may now happen if you have a pre-set errno coming into a > >>modified syscall > > Where does this happen that is not OK? It's true that my patch now > "tests" getxattr/setxattr to see if it may succeed and I thought that > was a neat solution. > I don't have any real-world examples where this breaks a program, I've just noticed the errno manpage says system calls or libraries won't zero out errno, In a situation where say, flistxattr is called with errno already set, and fakeroot catches a EPERM and fakes the result, it'll also zero out errno, violating the manpage's rule However, it is permitted to change errno on success, so the problem might just be the errno = 0 lines added with the #1136815 patch
