bug#61405: [PATCH] maint: fix some typos in comments

* NEWS : s/commmand/command/ * src/expand-common.c: s/specifed/specified/ * src/pr.c: s/e.g/e.g./ * tests/misc/comm.pl: s/ouput/output/ --- NEWS| 2 +- src/expand-common.c | 2 +- src/pr.c| 2 +- tests/misc/comm.pl | 2 +- 4 files changed, 4 insertions(+), 4

bug#61386: [PATCH] cp,mv,install: Disable sparse copy on macOS

On 10/02/2023 12:13, George Valkov wrote: On 2023-02-10, at 11:18 AM, Pádraig Brady wrote: I'll apply the simple patch later I think. I have an interesting idea: If I copy a large file, say the 16 GB disk image where I compiled OpenWRT. So I copy this on the same filesystem, and check disk

bug#61386: [PATCH] cp,mv,install: Disable sparse copy on macOS

> On 2023-02-10, at 11:18 AM, Pádraig Brady wrote: > > On 10/02/2023 03:57, Paul Eggert wrote: >> On 2/9/23 01:20, George Valkov wrote: >>> -#ifdef SEEK_HOLE >>> +#if defined(SEEK_HOLE) && !defined(__APPLE__) >> Instead of always disabling the SEEK_HOLE optimization, how about doing >> it only

bug#61386: [PATCH] cp,mv,install: Disable sparse copy on macOS

On 10/02/2023 03:57, Paul Eggert wrote: On 2/9/23 01:20, George Valkov wrote: -#ifdef SEEK_HOLE +#if defined(SEEK_HOLE) && !defined(__APPLE__) Instead of always disabling the SEEK_HOLE optimization, how about doing it only on APFS files? Something like the attached, perhaps (this is against

bug#61386: [PATCH] cp,mv,install: Disable sparse copy on macOS

On 10/02/2023 01:03, George Valkov wrote: On 2023-02-09, at 11:35 PM, Pádraig Brady wrote: On 09/02/2023 17:23, George Valkov wrote: On 2023-02-09, at 6:32 PM, Pádraig Brady wrote: On 09/02/2023 15:57, George Valkov wrote: On 2023-02-09, at 1:56 PM, Pádraig Brady wrote: On 09/02/2023

bug#61386: [PATCH] cp,mv,install: Disable sparse copy on macOS

On 2/9/23 01:20, George Valkov wrote: -#ifdef SEEK_HOLE +#if defined(SEEK_HOLE) && !defined(__APPLE__) Instead of always disabling the SEEK_HOLE optimization, how about doing it only on APFS files? Something like the attached, perhaps (this is against Savannah master). If APFS is pretty

bug#61386: [PATCH] cp,mv,install: Disable sparse copy on macOS

> On 2023-02-09, at 11:35 PM, Pádraig Brady wrote: > > On 09/02/2023 17:23, George Valkov wrote: >>> On 2023-02-09, at 6:32 PM, Pádraig Brady wrote: >>> >>> On 09/02/2023 15:57, George Valkov wrote: > On 2023-02-09, at 1:56 PM, Pádraig Brady wrote: > > On 09/02/2023 09:20,

bug#61386: [PATCH] cp,mv,install: Disable sparse copy on macOS

On 09/02/2023 17:23, George Valkov wrote: On 2023-02-09, at 6:32 PM, Pádraig Brady wrote: On 09/02/2023 15:57, George Valkov wrote: On 2023-02-09, at 1:56 PM, Pádraig Brady wrote: On 09/02/2023 09:20, George Valkov wrote: Due to a bug in macOS, sparse copies are corrupted on virtual

bug#61386: [PATCH] cp,mv,install: Disable sparse copy on macOS

> On 2023-02-09, at 6:32 PM, Pádraig Brady wrote: > > On 09/02/2023 15:57, George Valkov wrote: >>> On 2023-02-09, at 1:56 PM, Pádraig Brady wrote: >>> >>> On 09/02/2023 09:20, George Valkov wrote: Due to a bug in macOS, sparse copies are corrupted on virtual disks formatted with

bug#61386: [PATCH] cp,mv,install: Disable sparse copy on macOS

On 09/02/2023 15:57, George Valkov wrote: On 2023-02-09, at 1:56 PM, Pádraig Brady wrote: On 09/02/2023 09:20, George Valkov wrote: Due to a bug in macOS, sparse copies are corrupted on virtual disks formatted with APFS. HFS is not affected. Affected are coreutils install, and gcp when

bug#61389: Split issue

tag 61389 notabug close 61389 stop On 09/02/2023 12:53, Campbell Boyd wrote: Hi I've noticed that split puts a date on the split parts that is different from that of the file being split. To my mind the parts should have the same date and time as the file being split. Kind Regards and Stay

bug#61389: Split issue

Hi I've noticed that split puts a date on the split parts that is different from that of the file being split. To my mind the parts should have the same date and time as the file being split. Kind Regards and Stay Safe Campbell Boyd 07788520144

bug#61386: [PATCH] cp,mv,install: Disable sparse copy on macOS

On 09/02/2023 09:20, George Valkov wrote: Due to a bug in macOS, sparse copies are corrupted on virtual disks formatted with APFS. HFS is not affected. Affected are coreutils install, and gcp when compiled with SEEK_HOLE, as well as macOS Finder. While reading the entire file returns valid

bug#61386: [PATCH] cp,mv,install: Disable sparse copy on macOS

Due to a bug in macOS, sparse copies are corrupted on virtual disks formatted with APFS. HFS is not affected. Affected are coreutils install, and gcp when compiled with SEEK_HOLE, as well as macOS Finder. While reading the entire file returns valid data, scanning for allocated segments may return

bug#61300: wc -c doesn't advance stdin position when it's a regular file

On 2/6/23 11:38, Pádraig Brady wrote: Note also if you really want to read, you can always `cat | wc -c` rather than just `wc -c` Even that's not guaranteed, as 'cat' is not required to use the 'read' system call if it can determine that the standard input contains only NULs without calling

bug#61300: wc -c doesn't advance stdin position when it's a regular file

On 06/02/2023 06:27, Stephane Chazelas wrote: On 2023-02-05 20:59, Paul Eggert wrote: On 2023-02-05 11:59, Pádraig Brady wrote: [...] Let's leave that as-is, please. If 'wc' can output the correct value without reading its input, POSIX does not require 'wc' to do the read, and it seems

bug#61300: wc -c doesn't advance stdin position when it's a regular file

On 2023-02-05 20:59, Paul Eggert wrote: On 2023-02-05 11:59, Pádraig Brady wrote: [...] Let's leave that as-is, please. If 'wc' can output the correct value without reading its input, POSIX does not require 'wc' to do the read, and it seems perverse to modify 'wc' to go to the effort to refuse

bug#61300: wc -c doesn't advance stdin position when it's a regular file

On 2023-02-05 11:59, Pádraig Brady wrote: Hopefully the attached addresses this. Thanks for fixing that. Note it doesn't add the constraint on the input being readable, which I'll think a bit more about. Let's leave that as-is, please. If 'wc' can output the correct value without reading

bug#61300: wc -c doesn't advance stdin position when it's a regular file

On 05/02/2023 18:27, Stephane Chazelas wrote: "wc -c" without filename arguments is meant to read stdin til EOF and report the number of bytes it has read. When stdin is on a regular file, GNU wc has that optimisation whereby it skips the reading, does a pos = lseek(0,0,SEEK_CUR) to find out

bug#61300: wc -c doesn't advance stdin position when it's a regular file

"wc -c" without filename arguments is meant to read stdin til EOF and report the number of bytes it has read. When stdin is on a regular file, GNU wc has that optimisation whereby it skips the reading, does a pos = lseek(0,0,SEEK_CUR) to find out its current position within the file, fstat(0) and

bug#61267: shuf -i with negative numbers

tag 61267 notabug close 61267 stop comments below... On 03/02/2023 22:31, k...@plan9.lol wrote: hello shuf -i option cannot handle negative numbers. examples: $ shuf -i -10-20 $ shuf -i 0--20 don't know if it's a bug or a feature. The input range needs to be unsigned as documented in

bug#61267: shuf -i with negative numbers

hello shuf -i option cannot handle negative numbers. examples: $ shuf -i -10-20 $ shuf -i 0--20 don't know if it's a bug or a feature. :^) ~ kpm

bug#61248: uniq --unique needs examples

uniq INFO page says: ‘-u’ ‘--unique’ Discard the last line that would be output for a repeated input group. When used by itself, this option causes ‘uniq’ to print unique lines, and nothing else. This really needs some examples, to help people understand what it means.

bug#61035: [PATCH] cp: improve help regarding ACLs

On Tuesday, January 31, 2023 10:56:54 PM CET Paul Eggert wrote: > On 1/31/23 13:23, Ondrej Valousek wrote: > > Yes, that's nice, thanks! > > However I think it would be also fair to mention that ACLs will not be > > converted/translated (I.e. no posix to nfsv4 or vice versa). We are not > > that

bug#61035: [PATCH] cp: improve help regarding ACLs

On 1/31/23 13:23, Ondrej Valousek wrote: Yes, that's nice, thanks! However I think it would be also fair to mention that ACLs will not be converted/translated (I.e. no posix to nfsv4 or vice versa). We are not that clever. OK, I installed that along with the attached further patch to talk

bug#61035: [PATCH] cp: improve help regarding ACLs

Yes, that's nice, thanks! However I think it would be also fair to mention that ACLs will not be converted/translated (I.e. no posix to nfsv4 or vice versa). We are not that clever. Up to you really. Zasláno z Outlooku pro Android From:

bug#61035: [PATCH] cp: improve help regarding ACLs

OK, how about the attached more-ambitious patch instead? I hope it helps clarify this confusing area.From 1f5703b46cd8001706c1192a2976c7fc4d86002a Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 31 Jan 2023 10:39:43 -0800 Subject: [PATCH] cp: improve --preserve usage doc * src/cp.c

bug#61105: cp/mv: want a fatal --no-clobber

On 2023-01-31 09:11, Pádraig Brady wrote: To me --update is less useful if it fails in this case. Fair enough, I installed the attached to revert the --update part of the change, so that --update will work as before.From 01503ce7319b099d9deaeab43628e1b2b07a874a Mon Sep 17 00:00:00 2001 From:

bug#61105: cp/mv: want a fatal --no-clobber

On 31/01/2023 16:55, Paul Eggert wrote: On 2023-01-30 13:35, Pádraig Brady wrote: This is a good observation. Also the current "skip" functionality of coreutils cp -n is already catered for with the --update option. For consistency, there too the exit status should reflect whether the cp

bug#61105: cp/mv: want a fatal --no-clobber

On 2023-01-30 13:35, Pádraig Brady wrote: This is a good observation. Also the current "skip" functionality of coreutils cp -n is already catered for with the --update option. For consistency, there too the exit status should reflect whether the cp action was done. I installed the attached

bug#61105: cp/mv: want a fatal --no-clobber

On 30/01/2023 20:12, Paul Eggert wrote: Better, I think, would be to change cp -n to be compatible with FreeBSD, where 'cp -n A B' exits with status 1 if B exists. This matches what FreeBSD 'cp -i A B' does when you say "no". This would be more useful than what GNU cp does, and the FreeBSD cp -i

bug#61105: cp/mv: want a fatal --no-clobber

Better, I think, would be to change cp -n to be compatible with FreeBSD, where 'cp -n A B' exits with status 1 if B exists. This matches what FreeBSD 'cp -i A B' does when you say "no". This would be more useful than what GNU cp does, and the FreeBSD cp -i behavior conforms to POSIX whereas

bug#61035: [PATCH] cp: improve help regarding ACLs

> My understanding is that ACLs can be seen as extension over permission bits > whereas the extended attributes can store pretty > much anything. I am not saying which approach is (more) correct though. Exactly my point as well. Also, it is not correct to say "cp -p now preserves ACL" because

bug#61035: [PATCH] cp: improve help regarding ACLs

On Sunday, January 29, 2023 11:04:22 PM CET Paul Eggert wrote: > On 2023-01-29 03:06, Kamil Dudka wrote: > > On Wednesday, January 25, 2023 11:01:45 PM CET Paul Eggert wrote: > >> On 2023-01-25 13:56, Ondrej Valousek wrote: > >>> But it's not the same meaning. What I am trying to explain here is

bug#61035: [PATCH] cp: improve help regarding ACLs

On 2023-01-29 03:06, Kamil Dudka wrote: On Wednesday, January 25, 2023 11:01:45 PM CET Paul Eggert wrote: On 2023-01-25 13:56, Ondrej Valousek wrote: But it's not the same meaning. What I am trying to explain here is that Cp -p (or cp --preserve=mode) also retains ACLs. This fact is not

bug#61035: [PATCH] cp: improve help regarding ACLs

On Wednesday, January 25, 2023 11:01:45 PM CET Paul Eggert wrote: > On 2023-01-25 13:56, Ondrej Valousek wrote: > > But it's not the same meaning. What I am trying to explain here is that > > > > Cp -p (or cp --preserve=mode) also retains ACLs. This fact is not obvious, > > but yet it's

bug#33123: ls: add case-sensitive --color option

On 28/01/2023 19:31, Matt Martini wrote: Pádraig Thanks for the patch. Are there any plans to have this patch folded into coreutils? What is the process to make that happen? Is there anything I could do to help? I'm working on an improved version as my proposed one is a bit inefficient. I

bug#33123: ls: add case-sensitive --color option

Pádraig Thanks for the patch. Are there any plans to have this patch folded into coreutils? What is the process to make that happen? Is there anything I could do to help? Matt signature.asc Description: Message signed with OpenPGP

bug#61105: cp/mv: want a fatal --no-clobber

On 27 Jan 2023 23:59, Pádraig Brady wrote: > On 27/01/2023 20:52, Mike Frysinger wrote: > > basically i've been writing things like: > > if ! cp -n foo bar; then > >... error out because bar already exists, or otherwise failed ... > > fi > > > > when really i need to write: > > if [ -e bar ]

bug#61105: cp/mv: want a fatal --no-clobber

On 27/01/2023 20:52, Mike Frysinger wrote: i've been under the mistaken assumption that the -n/--no-clobber option exits non-zero when the target exists, but someone pointed out to me recently that it silently ignores existing files. can we get a setting to control this ? Yes

bug#61105: cp/mv: want a fatal --no-clobber

i've been under the mistaken assumption that the -n/--no-clobber option exits non-zero when the target exists, but someone pointed out to me recently that it silently ignores existing files. can we get a setting to control this ? basically i've been writing things like: if ! cp -n foo bar; then

bug#61050: mv: add support for --one-file-system

On 27/01/2023 19:13, Paul Eggert wrote: On 2023-01-25 05:34, Mike Frysinger wrote: should there be a `--copy` flag to be able to undo `--no-copy` ? We can add one if there's a need, but mv doesn't have a --clobber option to match its --no-clobber and I'm hoping --no-copy is similar.

bug#61050: mv: add support for --one-file-system

On 2023-01-25 05:34, Mike Frysinger wrote: should there be a `--copy` flag to be able to undo `--no-copy` ? We can add one if there's a need, but mv doesn't have a --clobber option to match its --no-clobber and I'm hoping --no-copy is similar. personally i always argue against using

bug#61035: [PATCH] cp: improve help regarding ACLs

On 2023-01-25 13:56, Ondrej Valousek wrote: But it's not the same meaning. What I am trying to explain here is that Cp -p (or cp --preserve=mode) also retains ACLs. This fact is not obvious, but yet it's happening Then I'm afraid I don't understand. In what sense do ACLs differ from xattr

bug#61035: [PATCH] cp: improve help regarding ACLs

But it's not the same meaning. What I am trying to explain here is that Cp -p (or cp --preserve=mode) also retains ACLs. This fact is not obvious, but yet it's happening Zasláno z Outlooku pro Android Od: Paul Eggert Odesláno: středa

bug#61035: [PATCH] cp: improve help regarding ACLs

On 2023-01-25 01:24, Ondrej Valousek wrote: For --preserve[=ATTR_LIST] the usage message says "preserve the specified attributes (default: mode,ownership,timestamps), if possible additional attributes: context, links, xattr," Yes, but that's nothing about ACLs. The aim of this patch is to

bug#61050: mv: add support for --one-file-system

On 25 Jan 2023 01:07, Paul Eggert wrote: > On 2023-01-24 17:20, Mike Frysinger wrote: > > i'd like to require that the mv be > > atomic when relocating a directory, and if it isn't, fallback to other > > logic > > Calling the new option "--one-file-system" sounds a bit wrong, as >

bug#61050: mv: add support for --one-file-system

On 25/01/2023 09:07, Paul Eggert wrote: On 2023-01-24 17:20, Mike Frysinger wrote: i'd like to require that the mv be atomic when relocating a directory, and if it isn't, fallback to other logic Calling the new option "--one-file-system" sounds a bit wrong, as --one-file-system is for

bug#61035: [PATCH] cp: improve help regarding ACLs

> For --preserve[=ATTR_LIST] the usage message says "preserve the specified > attributes (default: mode,ownership,timestamps), if possible additional > attributes: context, links, xattr," Yes, but that's nothing about ACLs. The aim of this patch is to clarify the current behavior which might

bug#61035: [PATCH] cp: improve help regarding ACLs

On 2023-01-25 00:26, Ondrej Valousek wrote: Doesn't the earlier part of the --help output already say something similar when it mentions xattr? It's OK for the --help output to be somewhat terse, with > longwinded details in the manual. No, I do not see a word there about ACLs For

bug#61050: mv: add support for --one-file-system

On 2023-01-24 17:20, Mike Frysinger wrote: i'd like to require that the mv be atomic when relocating a directory, and if it isn't, fallback to other logic Calling the new option "--one-file-system" sounds a bit wrong, as --one-file-system is for programs like 'du' and 'cp' and causes them to

bug#61035: [PATCH] cp: improve help regarding ACLs

> Doesn't the earlier part of the --help output already say something similar > when it mentions xattr? It's OK for the --help output to be somewhat terse, > with > longwinded details in the manual. No, I do not see a word there about ACLs

bug#61050: mv: add support for --one-file-system

mv will automatically use rename, but if that fails (e.g. with EXDEV), it falls back to copying files. i'd like to require that the mv be atomic when relocating a directory, and if it isn't, fallback to other logic. to that end, it'd be nice if mv supported --one-file-system and would return an

bug#61035: [PATCH] cp: improve help regarding ACLs

On 1/24/23 00:42, Ondrej Valousek wrote: +"), stdout); + fputs (_("\ +\n\ +--preserve=mode also copies ACLs but only if the destination filesystem\n\ +supports ACLs of the same type (i.e. no Posix <> NFSv4 ACLs conversion)\n\ Doesn't the earlier part of the --help output already say

bug#61035: [PATCH] cp: improve help regarding ACLs

Improve help to clarify ACL handling --- src/cp.c | 5 + 1 file changed, 5 insertions(+) diff --git a/src/cp.c b/src/cp.c index 016ae8988..73ffd34e9 100644 --- a/src/cp.c +++ b/src/cp.c @@ -239,6 +239,11 @@ When --reflink[=always] is specified, perform a lightweight copy, where the\n\ data

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

> The "at least in Linux" qualification worries me. > Having a very quick look at the qset_acl() code suggests it clears ACLs on > some platforms at least, which chmod_or_fchmod() does not. > Am I reading that wrong? You are right. The question is - why do we need to clear ACLs? The only real

bug#60989: [PATCH] rm: fail on duplicate input if force not enabled

On 22/01/2023 18:18, Philip Rowlands wrote: On Sat, 21 Jan 2023, at 13:05, Łukasz Sroka wrote: When the input files contain duplicates, then the rm fails. Because duplicates occur most often when the * is used and the shell unwraps it. There is a very common scenario when a user

bug#60989: [PATCH] rm: fail on duplicate input if force not enabled

On Sat, 21 Jan 2023, at 13:05, Łukasz Sroka wrote: > When the input files contain duplicates, then the rm fails. Because > duplicates occur most often when the * is used and the shell unwraps it. > There is a very common scenario when a user accidentally enters space > after a

bug#60989: [PATCH] rm: fail on duplicate input if force not enabled

On 21/01/2023 15:53, Pádraig Brady wrote: > > On 21/01/2023 13:05, Łukasz Sroka wrote: > > When the input files contain duplicates, then the rm fails. Because > > duplicates occur most often when the * is used and the shell unwraps > > it. > > There is a very common scenario when

bug#60989: [PATCH] rm: fail on duplicate input if force not enabled

On 21/01/2023 15:51, Łukasz Sroka wrote: On 21/01/2023 15:53, Pádraig Brady wrote: On 21/01/2023 13:05, Łukasz Sroka wrote: When the input files contain duplicates, then the rm fails. Because duplicates occur most often when the * is used and the shell unwraps it. There is

bug#60989: [PATCH] rm: fail on duplicate input if force not enabled

On 21/01/2023 13:05, Łukasz Sroka wrote: When the input files contain duplicates, then the rm fails. Because duplicates occur most often when the * is used and the shell unwraps it. There is a very common scenario when a user accidentally enters space after a filename, or

bug#60989: [PATCH] rm: fail on duplicate input if force not enabled

When the input files contain duplicates, then the rm fails. Because duplicates occur most often when the * is used and the shell unwraps it. There is a very common scenario when a user accidentally enters space after a filename, or enters space instead of forward slash.

bug#60981: Bug in man page for the "test" command

The man page already addresses this: Except for -h and -L, all FILE-related tests dereference symbolic links. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."

bug#60981: Bug in man page for the "test" command

Dear colleagues, this might have been reported before (or not), but there is a confusing description in the man page of the "test command: ### -e FILE   FILE exists -L FILE   FILE exists and is a symbolic link (same as -h) ### The problem here is the situation of a broken symlink. When flag

bug#60667: Close message

tag 60667 notabug close 60667 stop On 09/01/2023 05:35, Victor Engmark via GNU coreutils Bug Reports wrote: 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

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

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,

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

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

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

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

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

bug#60455: Missing fallback if copy_file_range returns ENOENT?

> On 7 Jan 2023, at 16:25, Pádraig Brady wrote: > > On 07/01/2023 07:34, Sam James wrote: >>> On 31 Dec 2022, at 18:51, Pádraig Brady wrote: >>> >>> On 31/12/2022 17:00, Sam James wrote: Hi folks, Originally reported in Gentoo at https://bugs.gentoo.org/885793. Frank Limpert

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

bug#60455: Missing fallback if copy_file_range returns ENOENT?

On 07/01/2023 07:34, Sam James wrote: On 31 Dec 2022, at 18:51, Pádraig Brady wrote: On 31/12/2022 17:00, Sam James wrote: Hi folks, Originally reported in Gentoo at https://bugs.gentoo.org/885793. Frank Limpert reported that when copying large files across CIFS shares, cp may abort

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

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 to qcopy-acl.c from Gnulib). Ondrej ---

bug#60455: Missing fallback if copy_file_range returns ENOENT?

> On 31 Dec 2022, at 18:51, Pádraig Brady wrote: > > On 31/12/2022 17:00, Sam James wrote: >> Hi folks, >> Originally reported in Gentoo at https://bugs.gentoo.org/885793. >> Frank Limpert reported that when copying large files across CIFS shares, >> cp may abort because copy_file_range

bug#60583: Support for new SI prefixes R, Q

On 2023-01-06 06:31, Pádraig Brady wrote: We ended up with almost exactly the same thing which is good. Oh, ouch, I had forgotten you'd posted that numfmt patch . Thanks for merging the results and correcting my mistakes.

bug#60591: `realpath` behaves differently when the target directory/file does not exist on Mac M1

tag 60591 notabug close 60591 stop On 05/01/2023 22:42, Tao Zhou wrote: Hi I recently noticed something weird with the `realpath` on my Mac Pro M1. When I try to call `realpath` on a directory/file that does not exist, it throws `No such file or directory` error, compared to another regular

bug#60489: Programs should exit after EIO from FICLONE or copy_file_range()

On 02/01/2023 16:22, Pádraig Brady wrote: On 02/01/2023 13:28, Andreas Schwab wrote: On Jan 02 2023, Pádraig Brady wrote: + /* Note error set is consistent with copy_file_range(). */ + bool no_clone_attempted = errno == ENOSYS || is_ENOTSUP (errno) +

bug#60583: Support for new SI prefixes R, Q

On 05/01/2023 21:11, Paul Eggert wrote: Building on Pádraig's Gnulib patches of November, I installed the attached to add support to Coreutils for the new SI prefixes R and Q. It'll be a while before 'df -h' outputs them, as I'm not expecting file systems in the ronnabyte range soon, given that

bug#60591: `realpath` behaves differently when the target directory/file does not exist on Mac M1

Hi I recently noticed something weird with the `realpath` on my Mac Pro M1. When I try to call `realpath` on a directory/file that does not exist, it throws `No such file or directory` error, compared to another regular Linux machine, the `realpath` there will just return a valid path, unless

bug#60583: Support for new SI prefixes R, Q

Building on Pádraig's Gnulib patches of November, I installed the attached to add support to Coreutils for the new SI prefixes R and Q. It'll be a while before 'df -h' outputs them, as I'm not expecting file systems in the ronnabyte range soon, given that the total amount of data storage in

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

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 'print "\xcd\xe5\xe0"; print "\n"' > file1 $ perl -e 'print "\xcd\xe5\xe0"x1000; print "\n"' > file2

bug#60512: tail: unrecognized file system type 0x794c7630

tag 60512 notabug close 60512 stop On 1/3/23 10:27, 闵续 wrote: tail: unrecognized file system type 0x794c7630 for ‘douyin.search.api.log’. please report this to bug-coreutils@gnu.org. reverting to polling Thanks for the report. That docker image seems to use a quite old coreutils version:

bug#60512:

tail: unrecognized file system type 0x794c7630 for ‘douyin.search.api.log’. please report this to bug-coreutils@gnu.org. reverting to polling

bug#58521: human readable still wrong output (after 20+ years?)

Paul Eggert wrote on 1/2/23 1:28 PM: Unfortunately backward-compatibility concerns are real, Such as? which means we're not likely to make a big change to -h's behavior at this point. You can use --si instead. While --si produces correct output, this does not address the subject of this

bug#59382: cp(1) tries to allocate too much memory if filesystem blocksizes are unusual

On 02/01/2023 23:18, Paul Eggert wrote: On 2023-01-02 15:03, Pádraig Brady wrote: On 20/11/2022 03:50, Paul Eggert wrote: Although we inadvertently removed support for weird devices in 2009 by commit 55efc5f3ee485b3e31a91c331f07c89aeccc4e89, and nobody seems to care (because people use dd or

bug#59382: cp(1) tries to allocate too much memory if filesystem blocksizes are unusual

On 2023-01-02 15:03, Pádraig Brady wrote: On 20/11/2022 03:50, Paul Eggert wrote: Although we inadvertently removed support for weird devices in 2009 by commit 55efc5f3ee485b3e31a91c331f07c89aeccc4e89, and nobody seems to care (because people use dd or whatever to deal with weird devices), I

bug#59382: cp(1) tries to allocate too much memory if filesystem blocksizes are unusual

On 20/11/2022 03:50, Paul Eggert wrote: Although we inadvertently removed support for weird devices in 2009 by commit 55efc5f3ee485b3e31a91c331f07c89aeccc4e89, and nobody seems to care (because people use dd or whatever to deal with weird devices), I think it'd be better to limit the fix to

bug#58521: human readable still wrong output (after 20+ years?)

On 2023-01-02 13:22, Chandler Sobel-Sorenson wrote: Unfortunately backward-compatibility concerns are real, Such as? I imagine lots of programs read the current output format. GNU 'sort' does. I haven't investigated all such programs. The current behavior has been in place since Larry

bug#58521: human readable still wrong output (after 20+ years?)

On 2022-10-14 09:24, chandler wrote: Please no excuses about how this will break other programs Unfortunately backward-compatibility concerns are real, which means we're not likely to make a big change to -h's behavior at this point. You can use --si instead. Assuming you're talking about

bug#60489: Programs should exit after EIO from FICLONE or copy_file_range()

On 02/01/2023 13:28, Andreas Schwab wrote: On Jan 02 2023, Pádraig Brady wrote: + /* Note error set is consistent with copy_file_range(). */ + bool no_clone_attempted = errno == ENOSYS || is_ENOTSUP (errno) +|| errno == EINVAL || errno ==

bug#60489: Programs should exit after EIO from FICLONE or copy_file_range()

On Jan 02 2023, Pádraig Brady wrote: > + /* Note error set is consistent with copy_file_range(). */ > + bool no_clone_attempted = errno == ENOSYS || is_ENOTSUP (errno) > +|| errno == EINVAL || errno == EBADF > +

bug#60489: Programs should exit after EIO from FICLONE or copy_file_range()

On 02/01/2023 06:36, Noah Misch wrote: Because Debian coreutils 9.1-1 "cp" silently falls back to copy_file_range() after FICLONE reports EIO, "cp" can transfer incorrect bytes. Linux syscalls having a file descriptor parameter report EIO after a fault in the underlying device. The affected

bug#60489: Programs should exit after EIO from FICLONE or copy_file_range()

Because Debian coreutils 9.1-1 "cp" silently falls back to copy_file_range() after FICLONE reports EIO, "cp" can transfer incorrect bytes. Linux syscalls having a file descriptor parameter report EIO after a fault in the underlying device. The affected file is not recoverable in the general

bug#60455: Missing fallback if copy_file_range returns ENOENT?

On 31/12/2022 17:00, Sam James wrote: Hi folks, Originally reported in Gentoo at https://bugs.gentoo.org/885793. Frank Limpert reported that when copying large files across CIFS shares, cp may abort because copy_file_range returns ENOENT sometimes. This sounds like a suspicious kernel bug if

<    4   5   6   7   8   9   10   11   12   13   >