'mv', 'install' now use openat etc. on destination directories

Following up on my recent 'cp' changes, I installed the attached so that 'mv' and 'install' are consistent with 'cp'. (I did a similar thing to 'ln' back in October 2018.)From 57c812cc3e17ecf5df887029221fe3f2d0cd7ea0 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 29 Jan 2022 11:40:17

bug#50745: coreutils-8.32 gnulib test results on hppa HP-UX 11.11

Thanks, that's a Gnulib report so I've forwarded it to bug-gnulib here: https://lists.gnu.org/r/bug-gnulib/2022-01/msg00177.html and am closing the Coreutils bug.

bug#51345: dd with conv=fsync sometimes returns when its writes are still cached

I found a bit of time to work on this and installed the attached patch, which should address the issue. Thanks for reporting it.From 3368b8745046aeaa89f418f560e714b374f1a560 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 28 Jan 2022 00:01:07 -0800 Subject: [PATCH] dd: synchronize output

bug#51433: cp 9.0 sometimes fails with SEEK_DATA/SEEK_HOLE

On 11/7/21 23:04, Paul Eggert wrote: https://github.com/openzfs/zfs/issues/11900#issuecomment-962812974 Apparently the OpenZFS bug has been fixed, as behlendorf closed it 20 days ago. Since there doesn't seem to be a good way for coreutils to work around the bug, and the bug potentially

bug#51482: dd with status=progress does not update its output when the main writing is finished

:00 2001 From: Paul Eggert Date: Thu, 27 Jan 2022 18:34:09 -0800 Subject: [PATCH] dd: output final progress before syncing Problem reported by Sworddragon (Bug#51482). * src/dd.c (reported_w_bytes): New var. (print_xfer_stats): Set it. (dd_copy): Print a final progress report if useful before

Having 'cat' use copy_file_range

the ones having to do with page-aligned buffer allocation which is something cat does). I installed the attached series of patches to do all that; the last patch is the copy_file_range change. From 7410f5cd0956f60c82c9306a3e07d26a31b3a29b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 16 Jan

Compilations warnings-as-errors when building from git

In Assaf Gordon writes: I'm getting few warnings-as-errors when building the latest version from git (using Debian 10 amd64 with gcc 8.3.0). I wouldn't worry about these. We typically don't bother to pacify older GCC versions as

Re: 'cp' now uses openat etc. when copying to directories

:00 2001 From: Paul Eggert Date: Sat, 15 Jan 2022 12:12:21 -0800 Subject: [PATCH] build: allow readlinkat calls MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Problem reported by Bernhard Voelker in: https://lists.gnu.org/r/coreutils/2022-01/msg00026.h

bug#53262: chmod 9.0 failing, where 8.29 succeeds - but no error message

Thanks for reporting that. This is a duplicate of bug#50784[1], which was fixed[2] in September. Perhaps we should generate a new Coreutils soon, since this bug has been reported three times now. [1]: https://bugs.gnu.org/50784 [2]:

'cp' now uses openat etc. when copying to directories

a git pull, since some of the Gnulib changes are needed for this.From e2daa8f79781882f194e90dc49632ece1e1edf01 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 12 Jan 2022 10:57:32 -0800 Subject: [PATCH] cp: when copying to dir use dir-relative names MIME-Version: 1.0 Content-Type: text/plain

bug#53037: df/total-verify fail with cephfs

On 1/5/22 15:25, Dylan Simon wrote: Hrm, no, with this patch it still fails, but differently (sorry so many filesystems): OK, then perhaps someone with a bit more free time will have to look at it - unless you can propose a patch that passed "make check".

bug#53037: df/total-verify fail with cephfs

On 1/5/22 14:11, Dylan Simon wrote: Then it will look like this (I'm inferring, haven't actually tried it): I'm still not quite following, but does the attached patch address the problem?diff --git a/src/df.c b/src/df.c index b803fc73b..8a0293ca9 100644 --- a/src/df.c +++ b/src/df.c @@ -127,6

bug#53037: df/total-verify fail with cephfs

On 1/5/22 11:27, Dylan Simon wrote: Only adding rows with all known values might make sense but would still break the test (wrong total total instead): if (known_value (iv->total) && known_value (iv->available)) { grand_fsu.fsu_files += iv->total; grand_fsu.fsu_ffree +=

bug#53025: Encouragement to go back to *dis*abled quotation marks in ls output as *default* behavior

On 1/5/22 00:44, Joerg M. Sigle wrote: "When this many people consider a thing a bug, then it's a bug whether maintainers disagree or not." By that standard it'll be a bug no matter what the maintainers do, since feelings are strong on both sides of the issue. So by this reasoning,

bug#17774: AIX and lbracket ([) program - will not install on AIX using installp

On 6/14/14 10:28, Paul Eggert wrote: That part of POSIX has been standardized since POSIX.2 (IEEE Std 1003.2-1992), and the wording hasn't changed since then if I recall correctly, so AIX has had this conformance bug for decades and nobody has cared I just ran into a related problem

new 'date' option --resolution and format %-N

just wide enough to cover the resolution.From 6812e6baa7882ed064d274ead8dcd84b556603ce Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 31 Dec 2021 00:45:03 -0800 Subject: [PATCH 1/5] build: port to AIX 7.1 This fixes a porting bug introduced in 2019-08-12T03:29:00Z!br...@clisp.org. Problem

bug#52873: expr unexpected syntax error

On 12/29/21 12:01, Martin Rixham wrote: What nonsense. I want to parse source code. ')' is not an uncommon line of source code. It should work. Unfortunately, you're asking for what is in general impossible. If the left argument of ':' could be any string, then the grammar for 'expr' would

bug#52873: expr unexpected syntax error

On 12/29/21 08:31, Davide Brini wrote: I think you need to use '+' before the offending token Yes. That's a GNU extension. If you want to be portable to any POSIX implementation, you can use this instead: expr "X(" : '.*' - 1 A similar example is given in the POSIX spec for 'expr':

bug#52844: missing perl not recognized properly by configure

ong we can reopen it. From c7bbfeb80c4be8d55074214e98c236eed8015a15 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 28 Dec 2021 01:53:44 -0800 Subject: [PATCH 1/2] build: update gnulib submodule to latest --- gnulib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gnulib b/gn

bug#52782: Man Page: Incorrect Summary of --color Option

eport.From 2269ea5aa2b8579ed2ec22407f55de4fd7218e4b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 24 Dec 2021 15:25:29 -0800 Subject: [PATCH] ls: improve doc for =WHEN * src/ls.c (usage): Improve clarity of =WHEN args (Bug#52782). --- src/ls.c | 16 +++- 1 file changed, 7 insertions(+), 9 deletions(-)

bug#52782: Man Page: Incorrect Summary of --color Option

e documentation uses the word "colorize" when it should say "color", so I installed the attached.From 2b30312f77f99efc8c56804424c4a317e25953f1 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 24 Dec 2021 09:47:18 -0800 Subject: [PATCH] doc: colorize -> color Living

bug#52656: (id) utility bug found

On 12/19/21 06:58, Glenn Golden wrote: Possibly the man page could be updated to say the same. Thanks for the suggestion. I installed the attached documentation patch and am closing the bug report.From d3beb53be64a958988a94ed86e6246a21dc95a9c Mon Sep 17 00:00:00 2001 From: Paul Eggert Date

bug#52525: wanted to add option to date command to handle pure numeric input in varying ways and output for invalid dates

On 12/15/21 14:24, Mike Marchywka wrote: if date is going to be a swiss army knife for date conversions it makes some sense to allow user selection of ambiguity resolution doesn't it? There are thousands of possible data conversions and I'm not sure we want to head down the road of trying to

bug#52525: wanted to add option to date command to handle pure numeric input in varying ways and output for invalid dates

On 12/15/21 12:39, Mike Marchywka wrote: $echo 2000 | date +%Y -f- 2021 How about this instead? The idea is to avoid adding features if they can easily be implemented with some other standard utility. This way, you can write your shell scripts now rather than waiting for a future fix (plus,

bug#52193: mv broken on non-APFS filesystems on macOS on coreutils >= 9.0

tached to implement this fix, the first patch into Gnulib, the second into coreutils.From dd474e50930ea00910631eb1b77ff4270d7b02c0 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 14 Dec 2021 12:32:30 -0800 Subject: [PATCH] renameatu: port to macOS tmpfs MIME-Version: 1.0 Content-Type: text

bug#52453: Full timezone name

On 12/12/21 07:27, 積丹尼 Dan Jacobson wrote: Also mention something about how to get the full timezone name. Unfortunately at the coreutils level that information is not available in any portable or reliable way.

bug#52410: "mv -T --backup=numbered hello world/" renameat2 infinite loop

ls and add a regression test.From d1b9e7c84959fb0f7014f03fc8746caa125f3d55 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 10 Dec 2021 13:31:02 -0800 Subject: [PATCH 1/3] backupfile: fix numbered backups for XXX/ MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Enco

bug#52193: mv broken on non-APFS filesystems on macOS on coreutils >= 9.0

9fe50d31aa75dd2d896225c2d1993f0b8eef2f26 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 8 Dec 2021 19:14:25 -0800 Subject: [PATCH] renameatu: port to macOS tmpfs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Problem reported by Sudhip Nashi (Bug#52193). * lib/renameatu.c

bug#52330: Different processor architecture on Apple M1 CPU

On 12/7/21 15:33, Jakub Sokołowski via GNU coreutils Bug Reports wrote: when is a new release planned for? I guess not before 2022? No current plans as far as I know.

bug#52330: Different processor architecture on Apple M1 CPU

Thanks for checking. I installed the patch and am closing the bug report.

bug#52330: Different processor architecture on Apple M1 CPU

On 12/7/21 04:03, Jakub Sokołowski wrote: src/uname.c:170:41: error: unknown type name 'MAYBE_UNUSED' I suspect you applied the patch to coreutils 9.0, which doesn't work. The patch needs to be applied to bleeding-edge coreutils built from Git

bug#52193: mv broken on non-APFS filesystems on macOS on coreutils >= 9.0

On 12/6/21 20:40, Sudhip Nashi wrote: The issue should be reproducible when moving directories and files within ~/mntpnt, but not between that filesystem and the parent APFS one, and vice versa. Thanks, but as I don't have access to a macOS machine I don't know what "the issue" is. What

bug#52330: Different processor architecture on Apple M1 CPU

, but the default uname utility on MacOS returns arm. Does the attached patch fix things for you? Unfortunately I don't have access to macOS to test it.From 202befd373ea4c851e4c3be85c52eeb108c6c7be Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 6 Dec 2021 14:39:22 -0800 Subject: [PATCH] uname: port

bug#52193: mv broken on non-APFS filesystems on macOS on coreutils >= 9.0

On 12/5/21 12:21, Sudhip Nashi wrote: it doesn’t look like the latest commit (the tarball you sent me) fixes the issue. Can you give a way to reproduce the probglem on a macOS system, assuming one has a tmpfs filesystem /A and a non-tmpfs filesystem /B? The scenario wasn't entirely clear

bug#52206: Bug: rm -rf /*/*

Thanks for explaining. As this is not an rm bug, I'm closing the bug report.

bug#52206: Bug: rm -rf /*/*

On 11/30/21 11:58, Robert Swinford wrote: This seems like a bug: https://twitter.com/nixcraft/status/1465599844299411458 I don't see a coreutils bug there: rm operated as specified. Interestingly, however, rm -rf // only does the following: Yes, that's a special feature of GNU rm. I

bug#52115: Suggestion: LN command should swap TARGET and LINK_NAME if LINK_NAME already exists

On 11/29/21 14:06, Bob Proulx wrote: mv calls it SOURCE and DEST. cp calls it SOURCE and DEST. Perhaps ln should also call it SOURCE and DEST too for consistency? That's what ln did long ago, but that wording was deemed too confusing. Here's where we changed it to use something more like

bug#52193: mv broken on non-APFS filesystems on macOS on coreutils >= 9.0

On 11/29/21 16:50, Sudhip Nashi via GNU coreutils Bug Reports wrote: It appears that in coreutils 9.0 and greater, the mv command is broken on non-APFS filesystems on macOS. For example, on Apple tmpfs, it fails whenever moving a file with ENOTSUPP. I don't observe this problem with the

bug#52115: Suggestion: LN command should swap TARGET and LINK_NAME if LINK_NAME already exists

On 11/29/21 02:34, Ulf Zibis wrote: I think, for beginners it would be less confusing, if the most simple form would be the first. Unfortunately the simple form "ln TARGET" is quite rarely used, so putting it first is likely to confuse beginners even more than what we have already. Come to

bug#52115: Suggestion: LN command should swap TARGET and LINK_NAME if LINK_NAME already exists

On 11/25/21 15:10, Warren Parad wrote: except mv(1) and cp(1) are both "FROM" and then "TO", but ln is backwards from thi, it is "TO" then "FROM" No, ln is exactly like mv and cp here: the source is the first argument, and the destination is the second. If this isn't clear, perhaps we

bug#52122: mv: deletes src file on error

On 11/26/21 04:23, Frank Busse wrote: I guess it was a hiccup somewhere else in the system, sorry. Thanks for following up; closing the bug report.

bug#52049: More Information

On 11/22/21 17:21, David McLaughlin wrote: Please disregard this, as there is no failure with shred version 8.30. Thanks for letting us know; closing the bug report

[PATCH] cp: clone on macOS

* configure.ac: Check for fclonefileat. * src/copy.c [HAVE_FCLONEFILEAT && !USE_XATTR]: Include . (copy_reg): If possible, use fclonefileat to clone. --- NEWS | 5 + configure.ac | 3 +++ src/copy.c | 12 3 files changed, 20 insertions(+) diff --git a/NEWS b/NEWS

[PATCH] cp: streamline cloning by skipping fstat

* src/copy.c (copy_reg): Attempt clone_file before fstat of dest, so that if clone_file succeeds we can skip the fstat. --- src/copy.c | 37 ++--- 1 file changed, 18 insertions(+), 19 deletions(-) diff --git a/src/copy.c b/src/copy.c index 9f20a34b9..97cc20d29

bug#52006: [INSTALLED] cp: fix --preserve=ownership permissions bug

This fixes a bug that I introduced in 2006-12-06T19:44:08Z!egg...@cs.ucla.edu. * src/copy.c (USE_XATTR): New macro. (copy_reg): Use it to help the compiler. Prefer open u+w to a later chmod u=rw; u+r isn’t needed for xattr. For the later u-r, do only one (or zero) chmod calls instead of two (or

[PATCH] maint: prefer MAYBE_UNUSED

Prefer MAYBE_UNUSED to _GL_UNUSED, since the C2x syntax will be [[maybe_unused]] at the start of the declaration, and we want to look forward to that. All uses of _GL_UNUSED either changed to MAYBE_UNUSED, or (when not needed) removed. --- src/chroot.c | 2 +- src/cksum.c | 3 +-- src/cksum.h

bug#11100: Racy code in copy.c

2001 From: Paul Eggert Date: Wed, 17 Nov 2021 13:22:06 -0800 Subject: [PATCH] cp: fix security context race MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This fixes an issue introduced in the fix for Bug#11100. * NEWS: Mention this. * src/copy.c (copy_reg

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

On 11/16/21 08:40, Sudhip Nashi via GNU coreutils Bug Reports wrote: It looks like this patch fixes the problem, and a quick checksum verifies this. Thanks for checking. Closing the Coreutils bug report.

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

agated it into coreutils. Please try the latest coreutils version on Savannah, or you can simply run configure+make from the tarball that is temporarily at: https://web.cs.ucla.edu/~eggert/coreutils-9.0.28-6d0f0.tar.gzFrom 1a268176fbb184e393c98575e61fe692264c7d91 Mon Sep 17 00:00:00 2001 From: Paul

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

agated it into coreutils. Please try the latest coreutils version on Savannah, or you can simply run configure+make from the tarball that is temporarily at: https://web.cs.ucla.edu/~eggert/coreutils-9.0.28-6d0f0.tar.gzFrom 1a268176fbb184e393c98575e61fe692264c7d91 Mon Sep 17 00:00:00 2001 From: Paul

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

On 11/15/21 16:02, Sudhip Nashi wrote: It doesn’t seem like this patch works. I compiled from the tarball you provided, but the destination file is still filled with NULL chars. Too bad. Can you do a dtruss or at least a ktrace/kdump for the failing program? I'd like to see what lseek is

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

://www.cs.ucla.edu/~eggert/coreutils-9.0.26-0f4d9.tar.gz Thanks.From 4db8db34112b86ddf8bac48f16b5acff732b5fa9 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 15 Nov 2021 15:08:25 -0800 Subject: [PATCH] lseek: port around macOS SEEK_DATA glitch Problem reported by Sudhip Nashi (Bug#51857

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

On 11/15/21 15:20, Pádraig Brady wrote: I also have access to a macOS system, so I'll also test out if there are ways to use SEEK_DATA there. Could you try the latest savannah Git instead? I installed something into Gnulib that I hope lets coreutils use SEEK_DATA on macOS as before. The

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

On 11/15/21 09:40, Cameron Katri wrote: No, this is one APFS (Apple File System). OK, so ZFS is not involved. unlink("/private/tmp/test\0", 0x0, 0x0)= 0 0 What's causing this use of "/private/tmp"? I don't see that in the GNU cp source code. Can you put a breakpoint on

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

Is the source file on a ZFS file system by any chance? See my lseek comment below. On 11/15/21 07:48, Cameron Katri via GNU coreutils Bug Reports wrote: stat64("/tmp/test\0", 0x16DDC36C0, 0x0)= 0 0 fstatat64(0xFFFE, 0x16DDC3C21, 0x16DDC2BA0) = 0 0

bug#51433: cp 9.0 sometimes fails with SEEK_DATA/SEEK_HOLE

It looks like the patch to OpenZFS might not suffice; see: https://github.com/openzfs/zfs/issues/11900#issuecomment-962812974 It looks like the OpenZFS folks are planning to look at it more this week. There is an obvious workaround (though it hurts performance)

bug#51433: cp 9.0 sometimes fails with SEEK_DATA/SEEK_HOLE

On 11/3/21 08:37, Pádraig Brady wrote: So this should unblock enabling coreutils 9 at some stage at least. That's good news. I've asked at [1] now they know what's going on, how programs might best distinguish buggy instances of openzfs. Maybe "configure" could do a "modinfo zfs" or a "cat

bug#51433: cp 9.0 sometimes fails with SEEK_DATA/SEEK_HOLE

On 10/31/21 09:13, Pádraig Brady wrote: The attached uses statfs()->f_type which is usually available, to avoid using SEEK_DATA on ZFS.  This should be fairly lightweight I think, and only used for files that might be sparse. Couldn't we be even lazier about invoking fstatfs? It needs to be

[PATCH 1/7] maint: prefer attribute.h in .c files

This will help us make the transition to C2x, where some attributes must come at the start of function decls. Leave the attributes alone in .h files for now, as the Gnulib tradition is to not expose attribute.h to users. * bootstrap.conf (gnulib_modules): Add ‘attribute’. * gl/lib/randperm.c,

[PATCH 7/7] maint: use minmax.h instead of rolling our own

* gl/lib/mbsalign.c, gl/lib/randread.c, src/system.h (MAX, MIN): Remove; include minmax.h instead. * gl/modules/mbsalign, gl/modules/randread (Depends-on): Add minmax. * src/factor.c (MIN): Remove. --- gl/lib/mbsalign.c | 6 ++ gl/lib/randread.c | 5 + gl/modules/mbsalign | 1 +

[PATCH 5/7] maint: enable -Wsuggest-attribute=format

* configure.ac (WERROR_CFLAGS): Enable -Wsuggest-attribute=format for lib/ and src/. * src/copy.c (copy_attr_error, copy_attr_allerror): Add ATTRIBUTE_FORMAT. (copy_attr): Ignore -Wsuggest-attribute=format in the small section of code that needs it ignored. * src/test.c (test_syntax_error): Mark

[PATCH 3/7] maint: remove unused __attribute__ defn

* gl/lib/randread.c (__attribute__): Remove; no longer used after the recent _Noreturn change. --- gl/lib/randread.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/gl/lib/randread.c b/gl/lib/randread.c index 5ed42b547..6c29a62e4 100644 --- a/gl/lib/randread.c +++ b/gl/lib/randread.c @@

[PATCH 6/7] maint: add function attributes to .h files

Add _GL_ATTRIBUTE_NONNULL, _GL_ATTRIBUTE_MALLOC, _GL_ATTRIBUTE_DEALLOC, _GL_ATTRIBUTE_DALLOC_FREE, _GL_ATTRIBUTE_RETURNS_NONNULL to .h files when appropriate. * gl/lib/mbsalign.h, gl/lib/randperm.h, src/chown-core.h: Include stdlib.h, for the benefit of _GL_ATTRIBUTE_DALLOC_FREE. *

[PATCH 4/7] maint: modernize attribute usage

* src/system.h (__attribute__): Remove. Replace all uses that rely on this by _GL_ATTRIBUTE_xxx or ATTRIBUTE_xxx. (ATTRIBUTE_WARN_UNUSED_RESULT): Remove. Replace all uses by NODISCARD. --- src/prog-fprintf.h | 2 +- src/stat.c | 36 src/stty.c

[PATCH 2/7] b2sum: simplify attribute usage

* src/blake2/blake2.h (BLAKE2_PACKED): Simplify, and port better to older GCC, by using _GL_ATTRIBUTE_PACKED. --- src/blake2/blake2.h | 16 +--- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git a/src/blake2/blake2.h b/src/blake2/blake2.h index 3960bdb2d..dc4672d1d 100644

bug#51011: [PATCH] sort: --debug: add warnings about radix and grouping chars

Thank you for working on this. Your points are well taken. One tiny comment: + if (basic_numeric_field) +{ + if (thousands_sep_ignored) This might be better combined as "if (basic_numeric_field && thousands_sep_ignored)", so that it's more similar to the previous "if".

bug#51507: ls incorrectly displays single quotes

On 10/29/21 13:32, Joel Hansen wrote: ls is incorrectly displaying single quotes around folders with spaces in them. This is confusing and unhelpful. Opinions evidently differ on that point. That being said, here's an example where the quotes help and where your suggestion of using -N

[PATCH] maint: modernize README-{hacking,prereq}

--- README-hacking | 60 +-- README-prereq | 96 +++--- 2 files changed, 70 insertions(+), 86 deletions(-) diff --git a/README-hacking b/README-hacking index be9ea3766..44cb75b98 100644 --- a/README-hacking +++

bug#51433: cp 9.0 sometimes fails with SEEK_DATA/SEEK_HOLE

b41425fbf7dc6d25a1a4d2fe322863fab597d65a Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 30 Oct 2021 10:00:10 -0700 Subject: [PATCH] cp: revert unnecessary FreeBSD workaround MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit That was a false alarm due to a bug

bug#51433: cp 9.0 sometimes fails with SEEK_DATA/SEEK_HOLE

On 10/28/21 13:59, Pádraig Brady wrote: I wonder after getting a SEEK_DATA ENXIO, might we correlate we really are at end of file by checking SEEK_HOLE also returns ENXIO? Wouldn't SEEK_HOLE return the current offset, instead of ENXIO? That is, if the underlying data structure is wrong and

bug#51433: cp 9.0 sometimes fails with SEEK_DATA/SEEK_HOLE

On 10/28/21 12:11, Paul Eggert wrote: Wait - lseek returns a number less than -1?! We could easily check for that FreeBSD bug, perhaps as an independent patch; this shouldn't require any extra syscalls. I installed the attached patch to do this. This doesn't fix coreutils bug#51433

bug#51345:

On 10/29/21 05:38, Pádraig Brady wrote: I'm leaning towards improving this by always doing an fsync on exit if we get a read or write error and have successfully written any data, so that previously written data is sync'd as requested. Sounds like a good idea to me too.

bug#51433: cp 9.0 sometimes fails with SEEK_DATA/SEEK_HOLE

On 10/28/21 06:54, Pádraig Brady wrote: Further debugging from Nix folks suggest ZFS was in consideration always, as invalid artifacts were written to a central cache from ZFS backed hosts. So we should at least change the comment in the patch to only mention ZFS. Yes, that sounds reasonable.

bug#51433: cp 9.0 sometimes fails with SEEK_DATA/SEEK_HOLE

, then an fdatasync or fsync on cp's input might work around common instances of this ZFS bug. Could you try the attached coreutils patch, and see whether it works around the bug? Or perhaps change 'fdatasync' with 'fsync' in the attached patch? Thanks.From 451c15fcb72e09afba499f188eb6e03ced49b1ca

bug#51011: [PATCH] sort: --debug: add warnings about radix and grouping chars

_("field separator %s is treated as a group separator in numbers"), quote (((char []) {thousands_sep, 0}))); number_locale_warned = true; } with a similar replacement to the decimal_point code. From 6cafb122fa214baa96a67fbbd2dab6c77a961e0a Mon Sep 17 00:00:00 2

bug#51011: [PATCH] sort: --debug: add warnings about radix and grouping chars

On 10/10/21 2:20 PM, Bernhard Voelker wrote: What about adding the hint to that message that this an "ambiguity warning"? I don't think it's ambiguous (merely confusing :-).

bug#51011: [GNU sort] Numerical sort with delimiter may be broken (bug)

On 10/9/21 5:00 AM, Pádraig Brady wrote: On 09/10/2021 04:48, Paul Eggert wrote: 'sort' could determine the group sizes from the locale, and reject digit strings that are formatted improperly according to the group-size rules. (Not that I plan to write the code to do that) Yes I agree

bug#51011: [GNU sort] Numerical sort with delimiter may be broken (bug)

On 10/8/21 7:32 PM, Pádraig Brady wrote: it's not a thousands separator, rather a grouping character, and groups can be in 2, 3, 4, and even 5. Sure, but 'sort' could determine the group sizes from the locale, and reject digit strings that are formatted improperly according to the

bug#51011: [GNU sort] Numerical sort with delimiter may be broken (bug)

On 10/8/21 6:37 AM, Pádraig Brady wrote: The difference here is due to ',' being treated as a thousands sep, not a decimal point. Oh, thanks. Of course! I should have figured that out myself. It is unfortunate that "," is treated as a thousands seperator even though it's obviously not one

bug#50940: how df utility displays sizes - GB vs GiB

On 10/4/21 13:31, Chris Murphy wrote: Is the primary target audience for human-readable values humans? Or scripts Both. Output columns are at a premium, so there is some advantage to omitting the units suffix (plus a lot of tradition for omission, outside of coreutils).

bug#51011: Problem solved - thoughts on confusing behavior

On 10/4/21 08:29, Juncheng Yang wrote: However, this is confusing because 1) the behavior of `-n` and `-g` are not consistent Yes, that is confusing. I have followed up to Pádraig about this. , 2) the `-n` in GNU sort is different from the sort on MacOS (which has pos2 as pos1+1 instead of

bug#51011: [GNU sort] Numerical sort with delimiter may be broken (bug)

On 10/4/21 08:58, Pádraig Brady wrote: The --debug option points out the issue:   $ printf '%s\n' 1,a 0,9 | sort --debug -nk1 -t ,   sort: key 1 is numeric and spans multiple fields   1,a   _   ___   0,9   ___   ___ As Juncheng points out, it is a bit odd that -n and -g disagree here,

bug#50972: src/ls.c fails to build when __GNUC_PREREQ is not defined (e.g., OpenBSD)

On 10/2/21 8:14 PM, Brian Callahan wrote: I can send you a build log offlist if you'd like to see what the 7.0 build looks like. It sounds like the more-recent clang has fixed most of the false alarms. It'd probably be a more-efficient use of our time for us to wait until 7.0 is out, so that

bug#50972: src/ls.c fails to build when __GNUC_PREREQ is not defined (e.g., OpenBSD)

On 10/3/21 4:38 AM, Pádraig Brady wrote: I'm confused as to why some functions need _Noreturn and some don't. Yes, it's a bit of a pain. _Noreturn is useful on extern functions, since otherwise GCC typically won't know the function doesn't return. On static functions, though, _Noreturn

bug#50972: src/ls.c fails to build when __GNUC_PREREQ is not defined (e.g., OpenBSD)

On 10/2/21 7:44 AM, Brian Callahan wrote: Once this fix is done, the rest of coreutils-9.0 builds and works OK. Thanks for letting us know, as it's been a while since I tried building coreutils on OpenBSD. I just now tried it on OpenBSD 6.9 and found some other problems that were easy to

bug#50940: how df utility displays sizes - GB vs GiB

On 10/1/21 2:16 PM, Glenn Golden wrote: Might it be possible to finesse the already existing envars (BLOCK_SIZE, DF_BLOCK_SIZE, etc.) to accomplish the desired suffixing mods? We've been moving away from using those environment variables, for security and reproducibility reasons.

bug#50940: how df utility displays sizes - GB vs GiB

On 10/1/21 1:30 PM, Danie de Jager wrote: Can we use the same options, but to trigger the longer annotation, we double the characters used to -hh and -HH? Interesting idea. Normally, later options override earlier, so 'df -h -H' is equivalent to 'df -H'. This is so that one can alias 'df' to

bug#50940: how df utility displays sizes - GB vs GiB

On 10/1/21 6:28 AM, Danie de Jager wrote: Systems like Amazon EC2 use the explicit GiB suffix. Are you saying that Amazon EC2's 'df' utility behaves differently from coreutils' 'df'? If so, could you send us documentation or source code indicating exactly what Amazon EC2's 'df' does? As

bug#50714: OS X, one failure: tests/tail-2/pipe-f.sh

On 9/21/21 6:08 AM, Pádraig Brady wrote: The attached fixes this on my testing on macOS. Thanks fixing this portability bug that I introduced. I also suggest changing this: #ifdef _AIX - /* select on AIX was seen to give

bug#50691: pwd: options with "--" (multiple dashes) return bad option

On 9/19/21 6:22 PM, william wrote: Do you know why command is necessary for it to recognize the option? Without 'command', you're using the builtin shell command rather than coreutils pwd. Closing the bug report, as this isn't a coreutils bug.

bug#50611: one-byte (write) heap-buffer-underrun

On 9/16/21 4:34 AM, Pádraig Brady wrote: It got me thinking though, that we should not we warning/failing on blank lines. I.e., we should be treating blank lines like comments. The attached does that. Thaks, a good improvement. The nerd in me also suggests changing this:

bug#50611: one-byte (write) heap-buffer-underrun

Thanks for reporting that. I installed the attached to fix it. >From 121f74dfc2e060a2ae174a636cd773f4d461a852 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 16 Sep 2021 00:17:18 -0700 Subject: [PATCH] cksum: fix off-by-1 bug with \r stripping Problem reported by Jim Meyering (Bug#50

bug#50484: Coreutils > Introduction

Thanks for reporting that. Fixed as per attached. >From 588790a38c78ccabe6ea9843ec9bce3ae78ecdba Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 9 Sep 2021 08:05:14 -0700 Subject: [PATCH] =?UTF-8?q?doc:=20can=20=E2=80=9Ccan=20can=E2=80=9D?= MIME-Version: 1.0 Content-Type: text/pl

bug#50432: DF shows incorrect disk usage which include disk usage of a mounted path

On 9/8/21 12:02 AM, Paco Xu wrote: I use this workaround to add `--local` and `-x` flag for `df` to avoid the wrong calculation. I got the workaround fromhttps://github.com/moby/moby/issues/42823#issuecomment-913584814. Thanks for following up; closing the bug report.

bug#50432: DF shows incorrect disk usage which include disk usage of a mounted path

It sounds like df is reporting disk usage for the file system you're running your docker instance atop. In that case, there may be other uses of the file system, aside from the docker instance, which means df is reporting the correct numbers (and du is, too). The problem, if it is a problem,

[INSTALLED 1/2] tests: merge help-version changes back from gzip

* tests/misc/help-version.sh: Merge gzip-related changes back from gzip/tests/help-version. This fixes problems when TERM is not 'dumb', and should simplify maintenance. --- tests/misc/help-version.sh | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git

[INSTALLED 2/2] tests: port better to NetBSD

* tests/misc/help-version.sh: Test that /dev/full causes shell printf to fail. This ports better to NetBSD 9.88.46, where it doesn’t. Problem reported by Nelson H. F. Beebe. --- tests/misc/help-version.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[INSTALLED] basenc: prefer signed to unsigned integers

This patch modifies basenc to prefer signed integers to unsigned, as signed are less error-prone. This patch also updates Gnulib to to latest, which updates Gnulib’s base32 and base64 modules to prefer signed to unsigned integers. * src/basenc.c: Include idx.h. (struct base2_decode_context): Use

bug#50167: fixes for "fmt - -" etc.

On 8/24/21 12:42 PM, Bernhard Voelker wrote: Was there a particular reason to include stdlib.h? It's needed to declare 'free', which is used by _GL_ATTRIBUTE_DEALLOC_FREE. I added "#include " so that find-mount-point.h would be an independent header, potentially useful outside coreutils. If

bug#50151: Coreutils, aarch64 and chroot

On 8/24/21 1:31 AM, Frans de Boer wrote: If it is the wrong executable, would it ever startup and continue and (try to) load bash or env? No. It even displays the help message! Not from what you've shown so far. You reported the output of env --help, not the output of chroot --help. I

<    1   2   3   4   5   6   7   8   9   10   >