GNU bug report logs - #60620
[PATCH] copy.c: replace set_acl() with chmod_or_fchmod()

Previous Next

Full log

Message #17 received at 60620 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ondrej Valousek <ondrej.valousek.xm <at> renesas.com>,
 "60620 <at> debbugs.gnu.org" <60620 <at> debbugs.gnu.org>
Subject: Re: bug#60620: [PATCH] copy.c: replace set_acl() with
 chmod_or_fchmod()
Date: Sun, 8 Jan 2023 15:18:59 -0800

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<https://aka.ms/AAb9ysg>
> ________________________________
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Sent: Sunday, January 8, 2023 12:53:37 AM
> To: Ondrej Valousek <ondrej.valousek.xm <at> renesas.com>; 60620 <at> debbugs.gnu.org <60620 <at> 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.
> 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.