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

On 2023-01-08 22:38, Ondrej Valousek wrote: 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... Well, perhaps I'm just misunderstanding the code.

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

Well, true, I do not know for sure what will happen on different platforms, yes - I can't test. On Linux both work the same way. Either case, the purpose of qset_acl() is to set ACLs the way so that it corresponds with the mode argument right? That's what I would expect how it's supposed to work.

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

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, Jan

bug#60667: Close message

Hi tl;dr Please close this. I sent a copy to coreut...@gnu.org after realising that was more appropriate, and I didn't think my bug-coreutils email would be registered since I wasn't a member. Sorry for the noise. Kind regards Victor Engmark

bug#60667: Split pathchk's -p into multiple flags?

Hi, I'd like to enforce the POSIX portable file name character set in my projects, which `pathchk -p` does, but I don't want to enforce the POSIX maximum path component length of 14 characters, which it also does. Would it be useful to introduce separate flags for the three rules enforced by `-p`?

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

bug#60544: sort hangs on lengthy line with invalid UTF8 characters

tag 60544 notabug close 60544 stop On 04/01/2023 04:38, DE CARNE DE CARNAVALET, Xavier [COMP] wrote: sort seems to do extra computations on long line with invalid UTF8 characters and could hang for days on just two lines. Here is the minimal example I could make to reproduce the bug: $ perl -e

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

On 06/01/2023 15:23, Ondrej Valousek wrote: This patch replaces set_acl() funclion call with chmod_or_fchmod() Both functions works (AFAIK) the same way (at least in Linux) so should be possible. Using chmod_or_fchmod would also help us to reduce dependency on libacl (see the forthcoming patch t

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

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 Zasláno z Outlooku pro Android

bug#60455: Missing fallback if copy_file_range returns ENOENT?

On 08/01/2023 00:51, Sam James wrote: On 7 Jan 2023, at 16:25, Pádraig Brady wrote: OK it's probably worth handling in coreutils then. Note I still get the feeling this is a race in CIFS that is only being made more apparent with copy_file_range(), but fair enough that this is a regression