bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30253: Fix for bug 21062 coreutils-8.24 - cp(1) check failures on tm


From: Pádraig Brady
Subject: bug#30253: Fix for bug 21062 coreutils-8.24 - cp(1) check failures on tmpfs filesystem (Solaris 10 / Solaris 11)
Date: Sat, 27 Jan 2018 16:59:01 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

forcemerge 21062 30253
stop

On 25/01/18 14:34, Alexander Pyhalov wrote:
> Hello.
> 
> I have a fix for 'bug 21062 coreutils-8.24 - cp(1) check failures on 
> tmpfs filesystem (Solaris 10 / Solaris 11)'.
> 
> The issue is that when on tmpfs we use acl(), trying to set ACL, it sets 
> errno to ENOSYS (ACLs not supported).
> set_acls still returns 0, but it spoils errno. When we do "cp -a", later 
> this ENOSYS appears in set_acls() results.
> (I still don't quite understand, why return code is not 0).
> The easiest fix here is to resetting errno to 0 when we are not going to 
> return non-zero result immediately
> 
> https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/sysutils/coreutils/patches/set-permission.c.patch

Thanks a lot for looking at this.
I also partially analyzed the issue at:
https://lists.gnu.org/archive/html/coreutils/2016-11/msg00095.html
with Andreas' response at:
https://lists.gnu.org/archive/html/coreutils/2016-12/msg00002.html

Your fix suggests there is an issue in the ret and errno handling.
This code is very hard to analyze without stepping through
and looking at the state.
On the face of it, setting errno=0 when returning 0 seems correct,
though looking at the code suggests that errno is never inspected unless ret!=0,
hence this might be masking a case where there is actually a failure and
some other error code is not being set.  Your resetting of errno to 0
may just be masking this failure to set an errno?

cheers,
Pádraig.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]