Not sure if I understand what you talk about. Qset_acl() is not copying any ACLs. How it could affect the code change we do to the qcopy_acl()? There is no change there... Zasláno z Outlooku pro Android ________________________________ From: Paul Eggert Sent: Monday, January 9, 2023 12:18:59 AM To: Ondrej Valousek ; 60620@debbugs.gnu.org <60620@debbugs.gnu.org> Subject: Re: bug#60620: [PATCH] copy.c: replace set_acl() with chmod_or_fchmod() On 2023-01-08 11:20, Ondrej Valousek wrote: > No, these two changes are (from the functional point of view) independent - i.e. acl handling will work regardless of the order these 2 are applied. > The only difference is, that once both are applied, we could link coreutils w/o libacl If the change quoted below is applied, but the Gnulib change is not, then ACLs won't be copied. So I don't see how the two changes are independent. > Zasláno z Outlooku pro Android > ________________________________ > From: Paul Eggert > Sent: Sunday, January 8, 2023 12:53:37 AM > To: Ondrej Valousek ; 60620@debbugs.gnu.org <60620@debbugs.gnu.org> > Subject: Re: bug#60620: [PATCH] copy.c: replace set_acl() with chmod_or_fchmod() > > On 2023-01-06 07:23, Ondrej Valousek wrote: >> - && qset_acl (dst_name, dest_desc, restrictive_temp_mode) != 0) >> + && chmod_or_fchmod (dst_name, dest_desc, restrictive_temp_mode) != 0) > > Doesn't this sort of change require the qcopy-acl.c change in Gnulib? If > so, we need to wait for that Gnulib change before installing this > change, right? Otherwise we won't be copying ACLs correctly. >