bug#68216: An instance of DD receiving data from another instance with bs=1M reports the wrong record count.

forcemerge 8171 68216 stop On 02/01/2024 10:45, ja...@johnstone.net.au wrote: Hi all, It seems an instance of `dd`  with only an output file doesn't report the count of records accurately despite bs= being described as influencing both ibs= and obs= dd'ing from an unstable remote over ssh toda

bug#68064: Date addition error with “day Monthname” versus “Monthname day”

tag 68064 notabug close 68064 stop On 27/12/2023 17:29, Larry Ploetz wrote: It seems like there might be a problem with date addition when the base date is specified as “day Monthname” instead of “Monthname day”, where the offset is being interpreted as an absolute year value. This may be locale

bug#62572: cp --no-clobber behavior has changed

On 16/12/2023 21:46, Bernhard Voelker wrote: On 12/15/23 21:13, Michael Stone wrote: On Fri, Dec 15, 2023 at 11:21:06AM -0800, Paul Eggert wrote: Stlll, Pádraig gave a reasonable summary of why the change was made, To clarify my summary a little, there I said that -n now _immediately_ fails.

bug#62572: cp --no-clobber behavior has changed

On 15/12/2023 15:56, Michael Stone wrote: I tend to think this was a serious mistake: it breaks the behavior of existing scripts with no deprecation period. A stated advantage is better compatibility with freebsd, but I don't understand why that is more desirable than compatibility with all deplo

bug#67756: autoconf-2.72d: bootstrap: The macro 'AC_PROG_GCC_TRADITIONAL' is obsolete.

nks, Pádraig commit 0d9547474d001e2903c18164d8929f5d2d2c0dd7 (HEAD -> master) Author: Pádraig Brady Date: Mon Dec 11 17:03:33 2023 + maint: remove obsolete AC_PROG_GCC_TRADITIONAL * configure.ac: Remove obsolete macro call. Recent autoconf warns that it is obsolete. AC_PROG_CPP sets up the -tr

bug#67765: ls: manual entry for -f mentions incorrect option

On 11/12/2023 09:38, Daniel Hofstetter wrote: Hi, The manual entry for -f on https://www.gnu.org/software/coreutils/manual/html_node/Sorting-the-output.html#index-_002df-9 contains: "[...] This is equivalent to the combination of --all (-a), --sort=none (-U), -1, --color=none, and --hyperlink=n

bug#67731: bootstrap, tries to fetch files although using --no-git --skip-po and --gnulib-srcdir...

| 6 ++ build-aux/bootstrap | 4 ++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index 1a3429e03b..b0d748029d 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2023-12-10 Pádraig Brady + + bootstrap: fix option propagation with

bug#67690: Bug in command sort?

tag 67690 notabug close 67690 stop On 07/12/2023 14:36, Oleg Moiseichuk via GNU coreutils Bug Reports wrote: Hello! I've got a list of IP addresses, each of them is prepended by its frequency counter (please find attached in the file list-1.txt). I need to sort them from most frequent to leas

bug#67680: nohup is not giving immunity to SIGHUP

tag 67680 notabug close 67680 stop On 07/12/2023 08:13, Bob Hepple wrote: $ nohup --version nohup (GNU coreutils) 9.3 $ uname -a Linux achar-void 6.5.12_1 #1 SMP PREEMPT_DYNAMIC Mon Nov 20 18:31:50 UTC 2023 x86_64 GNU/Linux This is on void, but it also behaves the same on fedora-38 I have extr

bug#67656: 'man touch' text about --time hard to read compared to 'touch --help'

On 06/12/2023 09:03, Arsen Arsenović via GNU coreutils Bug Reports wrote: Hi, In the manpage of touch, 'touch' flag --time is described as: --time=WORD change the specified time: WORD is access, atime, or use: equivalent to -a WORD is modify or mtime: equiv

bug#67626: column with -t and piped extends a single line file into multiple lines

tag 67626 notabug close 67626 stop On 04/12/2023 16:43, Remigiusz Suwalski via GNU coreutils Bug Reports wrote: Hi, today I have discovered accidentally that column utility behaves oddly when piped to another command, as shown on example below. I am not sure whether this is a bug or intended b

bug#67619: stty on Chromebook

tag 67619 notabug close 67619 stop On 04/12/2023 07:41, Dan Jacobson wrote: Seen on Chromebook: $ stty speed 38400 $ stty speed 1200 38400 $ stty speed 1200 1200 coreutils 9.4 "speed" only prints the current setting. A number on its own, sets the input and output speeds. So depending on the o

bug#67593: `split --number=l/N` no longer splits evenly

On 03/12/2023 09:37, Paul Eggert wrote: That's not a bug, in that 'split' is behaving as documented. The first input line is one byte shorter than the second one. 'Split' divides the input into two regions, and because the first region happens to be one byte longer than the second region both inp

bug#67490: [PATCH v2] tail: fix tailing sysfs files on large page kernels

On 01/12/2023 01:54, Paul Eggert wrote: On 11/30/23 12:11, Pádraig Brady wrote: Though that will generally give 128K, which is good when processing all of a file, but perhaps overkill when processing just the last part of a file. The 128 KiB number was computed as being better for apps like

bug#67490: [PATCH v2] tail: fix tailing sysfs files on large page kernels

Much clearer thanks. On my system: $ stat /sys/kernel/profiling File: /sys/kernel/profiling Size: 4096 Blocks: 0 IO Block: 4096 regular file I can easily repro by setting the buffer size < PAGE_SIZE. So this patch handles the case where sysfs reports a file is a c

bug#67490: [PATCH] tail: fix following /proc and /sys files when using a 64K page size

On 27/11/2023 16:24, dann frazier wrote: * src/tail.c (file_lines): Use fstat() to determine a file's block size and dynamically allocate a buffer of that size for traversing backwards. Thanks for the patch. Could you describe it a bit more. What happens if we use smaller reads? Also what about

bug#47103: numfmt: invalid suffix 'k'

On 26/11/2023 16:09, Sven Köhler wrote: So Pádraig's patch does allow for parsing lowercase k, but it does not change numfmt to use lowercase k in its output in si mode. As Pádraig has shown, ls uses lowercase k in --si mode. So it uses lowercase k for 1000. I think that numfmt should behave the

bug#47103: numfmt: invalid suffix 'k'

On 25/11/2023 21:27, Sven Köhler wrote: Not only --from=si is broken. Also --to=si is broken: $ numfmt --to=si 3000 3,0K In order to not break backwards compatibility, you probably have to introduce a switch --lowercase-kilo such that --to=si produces proper SI compliant output. Then have --fro

bug#67160: defect with linux expr command on chromebook build 118

tag 67160 notabug close 67160 stop On 14/11/2023 06:42, r n wrote: I have a lenovo slim 3 chromebook with linux version 5.15.130-etc and when expr encounter an asterisk for multiplying args, it return a syntax error unexpected argument 'code 1'. All other arithmetic operators are correctly inter

bug#66919: ls -l output is misaligned

On 03/11/2023 15:00, Vitaly Chikunov wrote: Hi, coreutils 9.4.0.24.75e248 seems to have regression where ls -l output is misaligned starting from size column. Example: /tmp$ ls -la total 8 drwxrwxrwt 18 root root 380 Nov 3 17:50 . drwxr-xr-x 26 root root 4096 Jul 24 18:44 .. drw

bug#66698: I think hex decoding with basenc -d --base16 should be case-insensitive

On 25/10/2023 02:30, Paul Eggert wrote: On 10/23/23 06:08, Pádraig Brady wrote: However the default operation should be the most common requirement (and also the RFC documented operation in this case). A similar case I hit very frequently is pasting hex into bc, and it's very annoying to

bug#66698: I think hex decoding with basenc -d --base16 should be case-insensitive

On 23/10/2023 13:50, Niels Möller wrote: Pádraig Brady writes: Will apply the attached later. Marking this as done. Thanks! It would make some sense to me to also have options --upper/--lower; on encoding, they would specify case of the output, on decoding, they would reject the other case

bug#66698: I think hex decoding with basenc -d --base16 should be case-insensitive

On 23/10/2023 10:37, Niels Möller wrote: Hi, the docs for basenc --base16 says "hex encoding (RFC4648 section 8)". The referenced section in that RFC says Essentially, Base 16 encoding is the standard case-insensitive hex encoding and may be referred to as "base16" or "hex". I think it w

bug#66519: b2sum, md5sum sha*sum etc broken on filenames including backslash

tag 66519 notabug close 66519 stop On 13/10/2023 13:31, Simon Richter M. Sc. wrote: I noticed some broken checksums with leading backslash and wrong filenames in my checksum files because the original filenames contained a backslash. Way to reproduce: % touch test\\test.file % b2sum test\\test.

bug#66265: Make padding optional with base64

Pushed. Marking this as done. cheers, Pádraig

bug#66265: Make padding optional with base64

On 29/09/2023 15:11, Pádraig Brady wrote: On 29/09/2023 10:46, Paul Millar wrote: Hi, RFC 4648 says[1]: > In some circumstances, the use of padding ("=") in base-encoded data > is not required or used. Currently, the 'base64' application always includes

bug#66265: Make padding optional with base64

On 29/09/2023 10:46, Paul Millar wrote: Hi, RFC 4648 says[1]: > In some circumstances, the use of padding ("=") in base-encoded data > is not required or used. Currently, the 'base64' application always includes the padding when encoding, and prints an warning/error message (on stderr)

bug#66256: sorting NAN values with "general-numeric’

On 28/09/2023 11:43, Jorge Stolfi wrote: The full documentation of the "--general-numeric-sort" option of {sort} says that NaN values are sorted "in a consistent but machine-dependent order". This is not good. The point of the IEEE floating-point standard was to make the results of floating-poi

bug#66253: sort manpage should be more explicit

On 28/09/2023 11:11, Jorge Stolfi wrote: The full documentation of sort explains that numeric sorting (as in "sort -n") accepts a leading "-" sign, decimal points, thousands separators, etc, but does not accept an explicit "+" sign. Values with explicit "+" are treated as numeric 0 and ties are b

bug#66056: tee Problem in 8.32, O.K in 8.30

tag 66056 notabug close 66056 stop On 17/09/2023 19:37, Pádraig Brady wrote: On 17/09/2023 18:32, Manfred Alfare wrote: Hi! Details described here: https://forums.linuxmint.com/viewtopic.php?t=404074 I don't think anything in tee has changed between 8.30 and 8.32, wrt carriage r

bug#66056: tee Problem in 8.32, O.K in 8.30

On 17/09/2023 18:32, Manfred Alfare wrote: Hi! Details described here: https://forums.linuxmint.com/viewtopic.php?t=404074 I don't think anything in tee has changed between 8.30 and 8.32, wrt carriage return handling, especially on linux. My best guess is that fsarcher has changed to do the eq

bug#65697: numproc, add flag to get number of available cores

On 02/09/2023 10:38, Simon Heimberg wrote: Hello Depending on what a process is mainly limited by, the ideal number of processes to run concurrently varies. A frequent use case is to run one process on each _physical_ core (which is available) than on each logical processing unit. I propose to i

bug#65659: [PATCH] printf: add %#s alias to %b

On 31/08/2023 19:31, Eric Blake wrote: POSIX Issue 8 will be obsoleting %b (escape sequence interpolation) so that future Issue 9 can change to having %b (binary literal output) that aligns with C2x. But since escape interpolation may still remain useful, POSIX suggested %#s (which is undefined

bug#65342: In Ubuntu 22.04 (unlike 20.04), sorting doesn't work properly

tag 65342 notabug close 65342 stop more info below... On 16/08/2023 16:55, Pl B wrote: Source file: rs1009150173,100202244031 rs1009150172,13853975996 rs1009150170,54321425962 rs1009150171,11378896079 rs1009150,171582090052 Ubuntu 20.04.5: sort -t ',' /path/to/rs_srt_exp.txt rs1009150,17158209

bug#65310: test failure on Alpine Linux: tests/sort/sort-debug-keys

On 15/08/2023 14:14, Bruno Haible wrote: Hi, Doing "make check" of current coreutils on Alpine Linux 3.18, I see a test failure that I didn't see with the coreutils-9.3 release: FAIL: tests/sort/sort-debug-keys I'm attaching the relevant part of tests/test-suite.log. In the log we have: +

bug#65294: [PATCH] maint: Fix compilation error on GNU/Hurd

On 14/08/2023 20:02, Bruno Haible wrote: Compiling a current coreutils on Debian GNU/Hurd from 2022, I get this compilation error: CC src/copy.o ../src/copy.c: In function 'set_author': ../src/copy.c:984:15: error: 'MACH_PORT_nullptr' undeclared (first use in this function); did you me

bug#65276: Build failure with gcc < 4.8

On 14/08/2023 00:46, Bruno Haible wrote: Building the current coreutils on GNU/kFreeBSD 7, I get link errors: CCLD src/cksum src/cksum-cksum.o: In function `pclmul_supported': /home/bruno/coreutils-2023-08-13/build-64/../src/cksum.c:149: undefined reference to `__builtin_cpu_supports' /h

bug#64954: GNU 'uptime' on OpenBSD always prints "0 users"

On 30/07/2023 20:43, Paul Eggert wrote: On 2023-07-30 11:41, Pádraig Brady wrote: I'm fine with the change, but we'll also need to adjust the sc_prohibit_always_true_header_tests syntax check in gnulib I looked into that but it's such a hassle that I came up with the attached s

bug#64954: GNU 'uptime' on OpenBSD always prints "0 users"

On 30/07/2023 15:44, Bruno Haible wrote: Hi, GNU coreutils-9.3 'uptime', on OpenBSD 7.2, prints 16:24:53 up 14 days 13:33, 0 users, load average: 0.04, 0.44, 0.59 whereas the OpenBSD /usr/bin/uptime prints 4:24PM up 14 days, 13:33, 1 user, load averages: 0.04, 0.44, 0.59 The utmp fil

bug#64937: "who" reports funny dates

On 30/07/2023 01:30, Paul Eggert wrote: On 2023-07-29 12:44, Pádraig Brady wrote: I tried a quick build with -D__WORDSIZE_TIME64_COMPAT32=1 which is what glibc uses to force the smaller time types. However that didn't fix the issue, so I'll need to look a bit more, and how to get

bug#64937: "who" reports funny dates

On 29/07/2023 17:41, Sven Joachim wrote: A 32-bit "who" program reports funny login dates: , | $ file src/who | src/who: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=a897e4f7a6dfd45c9245594e3d0b20497472c66d,

bug#64785: Package: coreutils Version: 8.32-4+b1 program=mv

On 22/07/2023 18:37, Paul Eggert wrote: On 2023-07-22 03:19, Pádraig Brady wrote: Given the subtleties in this area, I'd be reluctant to adjust diagnostics here. I looked into this a bit more. Given "mv dir e" where e/dir is an existing nonempty directory, 7th Edition Unix

bug#64785: Package: coreutils Version: 8.32-4+b1 program=mv

On 21/07/2023 18:17, Nir Oren wrote: *mv: error message "Directory not empty" is confusing * description: when you try to move a directory to a location already containing a directory with the same name it would just write "mv: cannot move 'A' to 'B': Directory not empty" first, this is technic

bug#64540: [PATCH] od: exit out on failure to write to stdout

On 17/07/2023 18:04, Paul Eggert wrote: On 2023-07-17 03:31, Pádraig Brady wrote: static inline void As a general rule, there's no need for 'static inline' in C, as nowadays compilers figure out inlining just fine for static functions and plain 'static' should

bug#64540: [PATCH] od: exit out on failure to write to stdout

On 17/07/2023 07:35, Bernhard Voelker wrote: On 7/15/23 23:08, Pádraig Brady wrote: The attached patch-set addresses two classes of issue: 1. Doubled error messages upon write errors 2. Continued processing upon write errors (the orig problem reported). Nice work! Patch 1: > --- /

bug#64654: input error handling

Just creating a bug to track the recent fixes to read error handling in various coreutils. I.e.: https://github.com/coreutils/coreutils/commit/9d333aca4 cksum https://github.com/coreutils/coreutils/commit/0e62ba282 tsort https://github.com/coreutils/coreutils/commit/5595673d5 numfmt https://gi

bug#64540: [PATCH] od: exit out on failure to write to stdout

On 09/07/2023 23:54, Pádraig Brady wrote: On 09/07/2023 20:11, Paul Eggert wrote: On 2023-07-09 07:11, Pádraig Brady wrote: Note the patch looks wrong as it would close the input always. We can fix that up easily enough anyway. If it's easy and doesn't hurt performance in the

bug#64588: BUG: stat -f incorrectly reports a BTRFS device as a tmpfs

On 13/07/2023 11:33, support wrote: Hmmm ok, Well the reason I flagged it as a bug, is because the btrfsmaintenance package uses a script to test to see if a filesystem is btrfs and incorrectly uses stat -f to do it. This must have worked in the past else they would not use it. The code snippet

bug#64588: BUG: stat -f incorrectly reports a BTRFS device as a tmpfs

tag 64588 notabug close 64588 stop On 12/07/2023 23:46, support wrote: coreutils version 9.1-1 on Debian testing, but also exists in previous versions. Example: stat -f  /dev/sdb   File: "/dev/sdb"     ID: eb91af7d7bda02dd Namelen: 255 Type: tmpfs Block size: 4096   Fundamental bl

bug#64392: cksum: escaping issues of --check output

On 01/07/2023 20:12, Christoph Anton Mitterer wrote: On Sat, 2023-07-01 at 18:53 +0100, Pádraig Brady wrote: That's not a common case I suppose, so I'm amenable to using the consistent escaping here. Good :-) Info docs already contain: "Without ‘--zero’, if FILE conta

bug#64540: [PATCH] od: exit out on failure to write to stdout

On 09/07/2023 20:11, Paul Eggert wrote: On 2023-07-09 07:11, Pádraig Brady wrote: Note the patch looks wrong as it would close the input always. We can fix that up easily enough anyway. If it's easy and doesn't hurt performance in the usual case, that's of course fine. For

bug#64540: [PATCH] od: exit out on failure to write to stdout

On 09/07/2023 10:29, Paul Eggert wrote: On 2023-07-08 15:43, Josef Bacik wrote: A very weird bug was uncovered when using fstests with github actions. In fstests we are doing something like this od /dev/urandom | dd of=somefile bs=1M count=10 The above works fine, except in the case of github

bug#64392: cksum: escaping issues of --check output

On 01/07/2023 18:20, Christoph Anton Mitterer wrote: On Sat, 2023-07-01 at 17:07 +0100, Pádraig Brady wrote: Right. We traditionally didn't escape any chars in the --check output, but that changed with https://github.com/coreutils/coreutils/commit/646902b30 To minimize escaping, that patch

bug#64392: cksum: escaping issues of --check output

On 01/07/2023 01:10, Christoph Anton Mitterer wrote: Hey. It seems to me that the output of --check mode in cksum (and likely also in md5sum and friends) suffers from improper escaping (which, IIRC, is not even documented for that output... but may be wrong): $ touch a $'new\nline' '\n' z $ ls

bug#64233: patch: Ensure that makeinfo ≥ 6.8 checks the @menu structure

On 22/06/2023 23:05, Bruno Haible wrote: Makeinfo versions < 6.7 detected mistakes in the @menu structure of TeXinfo input. Makeinfo versions ≥ 6.8 don't do this any more by default. They need an extra option, for this validation to happen. See

bug#64229: b2sum: heap-overflow in digest_check

On 22/06/2023 17:33, Frank Busse wrote: Hi, KLEE reported a heap-overflow in b2sum (Coreutils 9.3). When running it with: $ printf '\n\n0A0BA0' | coreutils-9.3/bin/b2sum -c (even '0BA0' seems to work on my machine) ASAN confirms the issue: #1 0x00473de0 in __interceptor_strchr (s=,

bug#64123: "stat -f -c '%T' ." on alpha fails with EOVERFLOW with NFS

On 17/06/2023 20:53, matoro wrote: On 2023-06-17 15:23, Paul Eggert wrote: On 2023-06-17 10:30, Pádraig Brady wrote: I see that s390 and alpha are the only 64 bit architectures that have a 32-bit ino_t for example, which may cause issues within glibc? Weird. What happens if you compile with

bug#64123: "stat -f -c '%T' ." on alpha fails with EOVERFLOW with NFS

On 17/06/2023 00:55, matoro via GNU coreutils Bug Reports wrote: Hi, when running the command "stat -f -c '%T' ." on an alpha while being on an NFS filesystem, the command fails with EOVERFLOW. $ stat -f -c "%T" . stat: cannot read file system information for '.': Value too large for defined dat

bug#64058: [PATCH] wc: Fix crashes due to incomplete AVX2 enumeration

On 14/06/2023 23:04, Paul Eggert wrote: On 6/14/23 03:46, Pádraig Brady wrote: Paul you removed the "avx" check from cksum.c. Was that intended? No, it's a typo I introduced. Thanks for catching that. Fixed in the first attached patch. While looking into this I noticed a

bug#64058: [PATCH] wc: Fix crashes due to incomplete AVX2 enumeration

On 14/06/2023 05:14, Paul Eggert wrote: Thanks for the bug report. I installed the attached patch into coreutils on Savannah. It builds on your idea with several other changes: * There's a similar issue with cksum.c and pclmul. * configure.ac can be simplified, since it seems there's no point c

bug#64027: [PATCH] dircolors: update list of backup file extensions

On 12/06/2023 21:27, Ville Skyttä wrote: * src/dircolors.hin: sort backup section by extension * src/dircolors.hin: treat .dpkg-new and .dpkg-tmp as backup files https://www.debian.org/doc/manuals/debian-handbook/sect.package-meta-information.en.html#sect.conffiles * src/dircolors.hin: treat .crd

bug#63931: ls colors one symlink too much as non-broken in symlink chain

On 07/06/2023 21:17, Paul Eggert wrote: On 2023-06-07 05:23, Pádraig Brady wrote: -    ? errno == ENOENT +    ? (errno == ENOENT || errno == ELOOP) This also needs a change in the succeeding comment, which starts "stat failed because of E

bug#63931: ls colors one symlink too much as non-broken in symlink chain

On 07/06/2023 13:23, Pádraig Brady wrote: On 07/06/2023 10:56, Martin Schulte wrote: Hello Paul, hello Pádraig, thanks a lot for your analysis and explanations! With that in mind, the code change you proposed is reasonably innocuous, although it slows things down a bit in the usual case. Not

bug#36887: coreutils-8.31: printf chokes on \u0041

On 07/06/2023 15:16, Ulrich Mueller wrote: Can this bug be closed? AFAICS it is fixed since coreutils-9.2. Relevant commit: https://git.savannah.gnu.org/cgit/coreutils.git/commit/src/printf.c?id=0925e8a0f413ecf9004153d89b312b385b20d0ee Marked as done. thanks! Pádraig

bug#63931: ls colors one symlink too much as non-broken in symlink chain

On 07/06/2023 10:56, Martin Schulte wrote: Hello Paul, hello Pádraig, thanks a lot for your analysis and explanations! With that in mind, the code change you proposed is reasonably innocuous, although it slows things down a bit in the usual case. Not sure it's worth doing (I guess it does fix

bug#63931: ls colors one symlink too much as non-broken in symlink chain

On 06/06/2023 18:24, Martin Schulte wrote: Hello coreutils-maintainers, I create a long chain of symlinks - ls colors the 41st element as ok while the kernel already gives up after 40 symlinks: $ uname -a Linux martnix4 5.10.0-23-amd64 #1 SMP Debian 5.10.179-1 (2023-05-12) x86_64 GNU/Linux $

bug#63850: cp fails for files > 2 GB if copy offload is unsupported

On 06/06/2023 11:02, Sam James wrote: Paul Eggert writes: On 2023-06-05 22:26, Sam James wrote: It's just that linux-headers is a special case Indeed it is. And apparently glibc avoids the copy_file_range bugs by never, ever using copy_file_range internally - which explains why glibc hasn'

bug#63850: cp fails for files > 2 GB if copy offload is unsupported

On 06/06/2023 06:48, Paul Eggert wrote: On 2023-06-05 22:26, Sam James wrote: It's just that linux-headers is a special case Indeed it is. And apparently glibc avoids the copy_file_range bugs by never, ever using copy_file_range internally - which explains why glibc hasn't run into this backwa

bug#63856: >=coreutils-9.2 cp: preserving permissions: Operation not supported when copying from no_root_squash nfs export

On 02/06/2023 18:29, Peter Robertson wrote: I have an nfs export: /mnt/Backup Hostname(no_root_squash,ro,mp) It exports this drive, LABEL=Backup/mnt/Backup btrfs noatime,compress-force=zstd:99 I have a locally mounted drive, /mnt/Mirror (LABEL=Mirror /mnt/Mirror btrfs

bug#63850: cp fails for files > 2 GB if copy offload is unsupported

On 03/06/2023 07:05, Paul Eggert wrote: On 2023-06-02 09:31, Pádraig Brady wrote: I'm not sure it was working correctly before 9.3 either. Before 9.3 we would have switched from copy_file_range() to read()/write() Actually, cp shouldn't have been using copy_file_range at all, as t

bug#63850: cp fails for files > 2 GB if copy offload is unsupported

On 03/06/2023 02:02, Mike Gilbert wrote: On Fri, Jun 02, 2023 at 05:31:50PM +0100, Pádraig Brady wrote: I'm not sure it was working correctly before 9.3 either. Before 9.3 we would have switched from copy_file_range() to read()/write() upon receiving the EINVAL, which might have worked

bug#63850: cp fails for files > 2 GB if copy offload is unsupported

On 02/06/2023 16:44, Sam James wrote: Hello, Forwarding a downstream report of a behaviour change between coreutils-9.1 and coreutils-9.3 from https://bugs.gentoo.org/907474. The reporter bisected it to 093a8b4bfaba60005f14493ce7ef11ed665a0176 ("copy: fix --reflink=auto to fallback in more case

bug#63784: date --date "1 month ago" +%Y-%m does not work as expected on day 31

On 29/05/2023 12:55, Jelle de Jong wrote: Hello everybody, I been hitting an issue for a while now that date commands return the wrong month on day 31 of a month and my automations stops working on correctly on these days. root@sydney:~# date Wed Aug 31 22:09:04 CEST 2022 root@sydney:~# date -

bug#63749: configure script does not work properly

tag 63749 notabug close 63749 stop On 27/05/2023 07:41, Мегахит wrote: Debian Sid amd64, building packages for Linux From Scratch *checking whether mknod can create fifo without root privileges... configure: error: in `/media/*usb mount directory*/sources/coreutils':* *configure: error: you sho

bug#63245: Potential regression: cp --preserve=mode or --preserve=all fails to copy files from subdirectory

On 05/05/2023 02:39, Sam James wrote: Pádraig Brady writes: On 04/05/2023 12:27, Pádraig Brady wrote: On 04/05/2023 07:27, Schlomo Schapiro wrote: Hi Pádraig, thank you, that will not yet fix the problem in the older distros? What about the RPM world with Fedora/RHEL and Archlinux? As far

bug#63245: Potential regression: cp --preserve=mode or --preserve=all fails to copy files from subdirectory

On 04/05/2023 12:27, Pádraig Brady wrote: On 04/05/2023 07:27, Schlomo Schapiro wrote: Hi Pádraig, thank you, that will not yet fix the problem in the older distros? What about the RPM world with Fedora/RHEL and Archlinux? As far as I can tell all cp version 9.x are affected by this. I&#x

bug#63245: Potential regression: cp --preserve=mode or --preserve=all fails to copy files from subdirectory

On 04/05/2023 07:27, Schlomo Schapiro wrote: Hi Pádraig, thank you, that will not yet fix the problem in the older distros? What about the RPM world with Fedora/RHEL and Archlinux? As far as I can tell all cp version 9.x are affected by this. I'll handle the Fedora 37/38 fixes. RHEL/Centos and

bug#63249: [404] broken link

On 03/05/2023 14:17, Adrien Kara via GNU coreutils Bug Reports wrote: Hi Gnu team, The link on https://www.gnu.org/software/coreutils/ section 'Enhancement Requests' for rejected feature requests are broken. Target: https://www.gnu.org/software/coreutils/rejected_requests.html There was an is

bug#63245: Potential regression: cp --preserve=mode or --preserve=all fails to copy files from subdirectory

On 03/05/2023 18:45, Schlomo Schapiro wrote: Hi Pádraig, Wow, nice! That was really quick! how would this patch get into the affected distros as a bugfix? Then it would actually help me as I can't ship a patched coreutils with ReaR. I expect the process would be something like: 1. merge thi

bug#63245: Potential regression: cp --preserve=mode or --preserve=all fails to copy files from subdirectory

On 03/05/2023 10:27, Schlomo Schapiro wrote: Hello, I'm a maintainer of the Relax-and-Recover (https://relax-and-recover.org/) Open Source project and think that I might have found a major regression in cp, starting somewhere with version 9. Please see https://bugs.launchpad.net/ubuntu/+source/

bug#63200: mongo-backup bug

tag 63200 notabug close 63200 stop On 01/05/2023 10:00, hatem ragap wrote: Hi, i have error with create backup to mongodb s3 it says 2023-05-01T08:58:36.422432890Z => Creating backup script 2023-05-01T08:58:36.425268363Z => Backup script created 2023-05-01T08:58:36.425276163Z => Creating restore

bug#63079: coreutils-9.3: build failure with -mno-ssse3

On 26/04/2023 00:22, Jaroslav Skarvada wrote: Hi, building with the -mno-ssse3 causes build failure, e.g.: CFLAGS="-O2 -march=bonnell -mtune=bonnell -mno-ssse3" ... gcc -I. -I./lib -Ilib -I./lib -Isrc -I./src -mavx -mpclmul -O2 -march=bonnell -mtune=bonnell -mno-ssse3 -c -o src/libcksum_pcl

bug#62572: cp --no-clobber behavior has changed

Take 2 attached. cheers, Pádraig From 849aa5658c0fbf1e8d2baec2fc3b01b2ddb23c50 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig=20Brady?= Date: Sat, 1 Apr 2023 16:27:52 +0100 Subject: [PATCH] cp,mv: add --update=none to always skip existing files Add --update=none which is equivalent to th

bug#62607: cp --recursive --backup broken in 9.2

On 03/04/2023 18:19, Pádraig Brady wrote: On 02/04/2023 13:40, Pádraig Brady wrote: For completeness the correct repro is: mkdir -p {src,dst}/foo touch {src,dst}/foo/bar cp --recursive --backup src/* dst The attached two patches should address this. The first fixes the bug in

bug#62607: cp --recursive --backup broken in 9.2

On 02/04/2023 13:40, Pádraig Brady wrote: On 01/04/2023 23:40, Kristian Klausen via GNU coreutils Bug Reports wrote: Hi After upgrading to coreutils 9.2-2 on Arch Linux the following: mkdir -p src dst touch {src,dst}/bar cp --recursive --backup src/* dst fails with: cp: cannot create regular

bug#62607: cp --recursive --backup broken in 9.2

On 01/04/2023 23:40, Kristian Klausen via GNU coreutils Bug Reports wrote: Hi After upgrading to coreutils 9.2-2 on Arch Linux the following: mkdir -p src dst touch {src,dst}/bar cp --recursive --backup src/* dst fails with: cp: cannot create regular file 'dst/foo/bar': File exists Running stra

bug#62572: cp --no-clobber behavior has changed

On 01/04/2023 23:44, Paul Eggert wrote: On 2023-04-01 08:44, Pádraig Brady wrote: OK first stab at --update=none support is attached. Thanks, some comments: + /* Always Overwrite. */ + UPDATE_OVERWRITE, Might be better to call this UPDATE_ALL as it doesn't overwrite if you use

bug#62572: cp --no-clobber behavior has changed

On 01/04/2023 00:29, Paul Eggert wrote: On 2023-03-31 14:32, Pádraig Brady wrote: Perhaps we should support:   --no-clobber[={skip, fail (default)}] so then users can at least easily change -n to --no-clobber=skip to get the old behavior? An alternative would be to augment the --update

bug#62572: cp --no-clobber behavior has changed

On 01/04/2023 15:46, Alberto Salvia Novella wrote: Also there's now a bigger problem: that you cannot tell when the copy failed because the file exists, or because any other reason. People will just use: cp --no-clover $in $out || true But if it fails for any other reason, cross your fingers.

bug#62572: cp --no-clobber behavior has changed

On 31/03/2023 22:15, Paul Eggert wrote: On 2023-03-31 13:37, Sven Joachim wrote: On 2023-03-31 13:01 -0700, Paul Eggert wrote: part of the idea was to let shell programmers easily test whether cp successfully copied the data. By making them stop using the '-n' option, since they cannot rely

bug#62542: coreutils-9.2: Failing tests on Adélie Linux

On 31/03/2023 07:27, A. Wilcox wrote: On Mar 30, 2023, at 9:48 AM, Pádraig Brady wrote: On 30/03/2023 09:20, A. Wilcox wrote: Hello, While updating coreutils to 9.2 on Adélie Linux, I’ve run into a few interesting corner-cases in the test suite. As a note, our distribution is using musl as

bug#62542: coreutils-9.2: Failing tests on Adélie Linux

On 30/03/2023 09:20, A. Wilcox wrote: Hello, While updating coreutils to 9.2 on Adélie Linux, I’ve run into a few interesting corner-cases in the test suite. As a note, our distribution is using musl as the libc. 1. `tests/misc/csplit-heap.sh` fails when /bin/sh is Bash I actually saw this on

bug#62497: maybe date -f should generate an error

On 28/03/2023 13:42, Pádraig Brady wrote: On 28/03/2023 09:54, Paul Eggert wrote: Thanks for reporting that. I installed the attached to fix it. Looks good thanks. Also worth the attached test and NEWS, which I've pushed. I'm also applying the attached for fix the same issue in

bug#62497: maybe date -f should generate an error

On 28/03/2023 09:54, Paul Eggert wrote: Thanks for reporting that. I installed the attached to fix it. Looks good thanks. Also worth the attached test and NEWS, which I've pushed. cheers, PádraigFrom a4525de1ef593cb3873eb88caa7279eb32669bda Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig

bug#62404: --reflink=auto not falling back appropriately on older kernels

The fix for this is now pushed at: https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=093a8b4bf marking this as done. thanks, Pádraig

bug#62404: --reflink=auto not falling back appropriately on older kernels

On 23/03/2023 22:57, Paul Eggert wrote: Thanks for looking into this. On 3/23/23 07:55, Pádraig Brady wrote: Perhaps we should use the above __ANDROID__ logic in all cases, so that we fallback unless there is a specific reason not to. Yes, that sounds better. +/* Whether the errno

bug#62404: --reflink=auto not falling back appropriately on older kernels

On 23/03/2023 13:39, Pádraig Brady wrote: On 23/03/2023 13:03, Pádraig Brady wrote: Details at https://github.com/termux/termux-packages/issues/15706#issuecomment-1481144831 But in summary, the new --reflink errno checking in coreutils 9.2 is not working appropriately on android 4.9 kernels at

bug#62404: --reflink=auto not falling back appropriately on older kernels

On 23/03/2023 13:03, Pádraig Brady wrote: Details at https://github.com/termux/termux-packages/issues/15706#issuecomment-1481144831 But in summary, the new --reflink errno checking in coreutils 9.2 is not working appropriately on android 4.9 kernels at least. Proposed patch attached. It may

bug#62404: --reflink=auto not falling back appropriately on older kernels

Details at https://github.com/termux/termux-packages/issues/15706#issuecomment-1481144831 But in summary, the new --reflink errno checking in coreutils 9.2 is not working appropriately on android 4.9 kernels at least. cheers, Pádraig

bug#62403: checksums --check (sha256sum, sha1sum) return file: OK when they shouldn't

On 23/03/2023 09:32, Moviuro via GNU coreutils Bug Reports wrote: Hello, This report was first found on r/archlinux: % echo "123" > 1 % echo "1234" > 2 % echo "abc" > 3 % sha256sum 1 2 3 > sums.sha256 % sha1sum 1 2 3 > sums.sha1 % echo "123" > 2 # break file 2 % sha256sum -c sums.sha256 # retu

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