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

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 simpler patch to Coreutils. How about installing it inste

bug#64937: "who" reports funny dates

On 2023-07-30 04:02, Pádraig Brady wrote: Yes I think the consensus is to switch away from the utmp API, which was recently discussed at: https://lists.gnu.org/archive/html/coreutils/2023-06/msg00024.html If I understand that discussion correctly, the idea is to switch from utmp/utmpx to the s

bug#64937: "who" reports funny dates

and/or Fedora's plan for fixing /'s Y2038 bugs? (Or is the idea to remove the API before 2038? :-) See: https://lwn.net/Articles/925068/ https://sourceware.org/glibc/wiki/Y2038ProofnessDesign#utmp_types_and_APIsFrom c408d9a53dbdaf48b555f216e250a2b3b8e48113 Mon Sep 17 00:00:00 2001 F

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

linkat, where the diagnostic could be improved if it's known to refer to the destination.From 3cb862ce5f10db392cc8e6907dd9d888acfa2a30 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 22 Jul 2023 13:39:17 -0700 Subject: [PATCH] mv: better diagnostic for 'mv dir x' failure Problem

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

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 fails this way: mv: e/dir exists Solaris 10 mv fails th

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

On 2023-07-17 10:12, Pádraig Brady wrote: Right. In headers though, the traditional "static inline" idiom Ah, I forgot that it was in system.h. At some point we should have system.h use _GL_INLINE but that can wait.

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

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 be good enough. There are exceptions but 'write_error' doesn't look lik

bug#64604: readlink exit booelan value bug

On 2023-07-13 19:38, Budi wrote: /tmp$ readlink -f ./KERNEL-linux-6.3.9 && echo SUCCEEDS FIND IT /tmp/KERNEL-linux-6.3.9 SUCCEEDS FIND IT but correct at deeper depth: /tmp$ readlink -f ./KERNEL-linux-6.3.9/fs && echo SUCCEEDS FIND IT look it up, no KERNEL-linux-6.3.9 dir.: That's not a b

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

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 my reference a short list of utils to check (that might

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

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 actions which runs this script remotely,

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

On 2023-06-17 12:53, matoro via GNU coreutils Bug Reports wrote: Compiling with -D_FILE_OFFSET_BITS=64 fixes the problem. Thanks for checking. I installed the following fix to coreutils: https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=5ac7f2d281ef70500fc70211dc1f146c8666e8c1 This i

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

On 2023-06-17 15:19, Pádraig Brady wrote: In case it's useful, I noticed this thread from 2014 about ino_t and consequences of using -D_FILE_OFFSET_BITS=64 https://sourceware.org/pipermail/libc-alpha/2014-March/thread.html#49675 Yes, that was about glibc. For Autoconf and Gnulib it's long been

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

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 -D_FILE_OFFSET_BITS=64? Does this cause alpha to have a 64-bit ino_t? (How d

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

other attached patches. I installed these into coreutils on Savannah.From 7814596fa91a07fb2f1d0972f93f26de8a4ad547 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 14 Jun 2023 14:13:35 -0700 Subject: [PATCH 1/3] cksum: fix bug in check for cksum_pclmul MIME-Version: 1.0 Content-Type: text/plain

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

NEWS file?From 91a74d361461494dd546467e83bc36c24185d6e7 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 13 Jun 2023 21:10:24 -0700 Subject: [PATCH] wc: port to kernels that disable XSAVE YMM Problem reported by Dave Hansen <https://bugs.gnu.org/64058>. Apply similar change to cksum and pclmul, too. *

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

On 6/8/23 04:28, Arsen Arsenović wrote: Please reconsider dropping the configure-time version check. I already dropped it, so this discussion is more about the general principle than this particular case. It is entirely reasonable to expect that a user will roll back a kernel update, as the

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

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 ENOENT"

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

On 2023-06-07 12:21, Sam James wrote: I don't see how this is compatible with what I explained, given you can't have parallel linux-headers installs. Nobody uses glibc in a vacuum, either, so it's not particularly meaningful to say you can use glibc but nothing else in that way. If you object

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

On 2023-06-06 03:02, Sam James wrote: Thanks Paul. Do you know if there's any other cases of this in gnulib? There's no other use of linux/version.h in Gnulib. However, this doesn't mean there are no other instances of the problem, as it's common to assume that you'll run on a host no older t

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

On 6/6/23 13:32, Pádraig Brady wrote: I'll think a bit more about it and add a test before applying. I wouldn't test that the 'ls' output exactly matches the 'cat' output. For example, it should be OK for stat_for_mode to pass the parent directory fd (instead of AT_FDCWD) to statx, for effici

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

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 backward compatibility issue. Presumably once

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

older kernels. In other words, something like the attached patch should be more reliable than the other band-aids proposed.From 87b95c17dc8611f9483b966d052eefc930f43927 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 5 Jun 2023 22:04:37 -0700 Subject: [PATCH] copy-file-range: support

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

On 2023-06-03 06:54, Mike Gilbert wrote: In this case, headers from linux-6.1 are being used at build time. However, the code is being run on a linux-4.19 kernel. Gnulib doesn't support that. If you build with headers from a particular version of the operating system, you can't necessarily run

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

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 the code is supposed to never use copy_file_range unle

bug#63349: Bug in date when using UTC/GMT timeszones in the TZ variable

; documentation (admittedly only a subset of 'date' users). From 9f205ff9624b8e10b4331432c59bc732b8c1a7fe Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 7 May 2023 09:28:57 -0700 Subject: [PATCH] Warn against bogus TZ settings * doc/parse-datetime.texi (Specifying time zone rules

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

.From 300af7869161a3618e28cbae3daefc25c8267efe Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 5 May 2023 11:03:25 -0700 Subject: [PATCH] cp: -p --parents: minor cleanup of previous patch MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This doesn’t change behavio

bug#63119: date -Ins has a comma!!

On 4/27/23 07:53, aaa jjj wrote: What does ISO 8601 say about this? I believe ISO 8601-1:2019/Amd 1:2022 prefers a comma, though a period is allowed. Unfortunately I can't easily check this because the standards are not published online and you need to pay to read them. Isn't ISO wonderful?

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

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 cp -l or -s or (in some cases) --preserve=links

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

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 option to support:   --update[={none, older (

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

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 on the exit code anyway? Por

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

On 2023-03-31 10:01, Alberto Salvia Novella wrote: Is this on purpose? Yes, part of the idea was to let shell programmers easily test whether cp successfully copied the data. Having cp -i conform to POSIX was a lesser consideration, though it's a bit nicer if -n and -i are somewhat consisten

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

Thanks for reporting that. I installed the attached to fix it.From 9c5e542fd190a14431092e3b6cb45d18fe95f26f Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 28 Mar 2023 01:52:43 -0700 Subject: [PATCH] date: diagnose -f read errors * src/date.c (batch_convert): Diagnose read errors, fixing

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

ioctl(4, BTRFS_IOC_CLONE or FICLONE, 3) = -1 EOPNOTSUPP newfstatat(4, "", ..., AT_EMPTY_PATH) = 0 as there should be no need to stat the source twice, or to try to open the destination twice. But this is a performance improvement for another day.From 6272817de007d236f82616df5916be373

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

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 indicates operation is a transient failure. + I

bug#62405: date update

On 3/23/23 06:18, Edgar Aquino Rodriguez wrote: if i run date (system time) Thu Mar 23 07:15:39 MST 2023 i dont now but if i run date --custom Thu Mar 23 13:34:15 MST 2023 or how can get multiple timezones in the same system Although it's not clear what you're asking for, but perhaps these ex

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

On 3/21/23 08:27, George Valkov wrote: However since the old m4-1.4.19 in under tools/m4, coreutils builds with the legacy version: If you're building from that tarball, coreutils doesn't need m4. I just now double-checked that, in an environment that didn't have m4. "./configure && make che

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

On 3/21/23 06:55, George Valkov wrote: Is there a source download link or should be clone from the Savanna git repo? Easiest might be to build from the latest release: https://ftp.gnu.org/pub/gnu/coreutils/coreutils-9.2.tar.xz If you do that, you shouldn't need to run m4, and all the gnulib f

bug#62179: A problem with Gnu or Linux or Google Drive

This is not a bug in tar or in Emacs, nor is it a bug in coreutils. It's a problem with Google Drive or with the Linux kernel driver, so I suggest contacting whoever's in charge of that (I don't know who that is). I'm closing the coreutils bug report.

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

kill. I installed the attached patch so that 'split' uses a temp file in this situation, so it is no longer limited to the 128 KiB size that it was before the attached patch. Hope this is good enough; if not please let me know. make-check-log.txt.gz Description: application/gzip From b

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

On 3/6/23 03:13, Pádraig Brady wrote: On 06/03/2023 07:37, Paul Eggert wrote: The lseek /dev/null issue was only in your undef SEEK_DATA test patch, and already addressed in your final gnulib patch in the area, as discussed at: https://lists.gnu.org/archive/html/bug-coreutils/2023-02/msg00081

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

I recall reading somewhere in this thread that a 'split' test was failing on macOS because it doesn't let you lseek on /dev/null. I fixed that problem here: https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=aa266f1b3dc4e12acdc46cc0f562adc03c2c0b8f and fixed some other 'split' issues i

bug#61884: add an option to du that allows to control which file types are counted

On 2023-03-04 17:20, Christoph Anton Mitterer wrote: Would you mind to add a shorter notice to the manpage as well? The manpage is terse by design, and I doubt whether this minor detail makes the cut.

bug#61884: add an option to du that allows to control which file types are counted

the right thing for your use case. So I installed the attached patch to fix du --apparent to count sizes only when st_size is well-defined. This should address your use case so I'm boldly closing the bug report.From 110bcd28386b1f47a4cd876098acb708fdcbbb25 Mon Sep 17 00:00:00 2001 From: Pa

bug#61884: add an option to du that allows to control which file types are counted

What's the motivation here? Does this have something to do with reproducible builds? One possibility is for --apparent-size to always count 0 for directories, since 'read' never returns a positive number on directories. That is, we reinterpret --apparent-size to mean "bytes that could be read

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

rg/software/gnulib/manual/html_node/lseek.html>. So I thought it nicer to leave it in for now; it has zero runtime cost on all platforms. From 7352d9fec59398c76c3bb8a2ef86ba58818f0342 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 19 Feb 2023 00:05:24 -0600 Subject: [PATCH] lseek: avo

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

fixed in macOS 13. I'll cc this email to bug-gnulib to give them a heads-up. (Gnulib readers can see <https://bugs.gnu.org/61386> for context.) Really, Apple should fix this serious data corruption bug in APFS and macOS. From 0024b8460dfe5e133f9e0d63ed4f75314dea2f82 Mon Sep 17 00

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

On 2/16/23 13:32, Pádraig Brady wrote: +  /* any desired permissions that weren't cloned.  */    extra_permissions = desired_mode & ~cloned_mode; That comment is a tad redundant, but I did add some commentary along those lines and installed the patch into Savan

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

On 2023-02-15 07:26, George Valkov wrote: I tested your patch: both overwrite existing and clone to new produce a working copy. Here are the test results: https://httpstorm.com/share/.openwrt/test/2023-02-06_coreutils-9.1/test-04-cf80f988eeb97cc3f8c65ae58e735d36f865277b-clone.txt I see some te

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

On 2023-02-15 06:05, George Valkov wrote: gcc d.c && ./a.out src 3 dst 4 c 14053376 p 20344832 h 20344832 d 6291456 total bytes copied 14053376 / 27551296 Thanks, this is due to a known incompatibility in macOS lseek that coreutils is supposed to work around. See

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

, given that Apple had so many problems fixing its own security bug involving fclonefileat, and given that the coreutils code has so many flags and conditions. From 9bb98016eb3a369c3ae195b71fcc1010e5aa6e53 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 10 Feb 2023 13:34:54 -0800 Subject

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

On 2023-02-14 04:12, Pádraig Brady wrote: I suspect it's a similar issue to the one that openzfs had: https://github.com/openzfs/zfs/issues/11900 Yes, quite likely. Given how closed / uncommunicative Apple are in general and specifically for this already reported bug, I'm inclined to disabl

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

bugging this sort of thing. It's what helped us debug Bug#51857.From 4db8db34112b86ddf8bac48f16b5acff732b5fa9 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 15 Nov 2021 15:08:25 -0800 Subject: [PATCH 1/2] lseek: port around macOS SEEK_DATA glitch Problem reported by Sudhip Nashi (Bug#

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

On 2023-02-11 16:38, George Valkov wrote: This might help: https://github.com/apple/darwin-xnu/blob/main/bsd/sys/clonefile.h It doesn't help, because it doesn't mention CLONE_ACL. The kernel should be open source. No, the macOS kernel is not free software. Nor is iOS's kernel.

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

cp should not unlink and re-create the destination. Of course we can add a non-POSIX flag to do that, and we already have: cp --remove-destination.From ea8904606e8e749e2f6d22c1abb0310fac3722f5 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 10 Feb 2023 13:34:54 -0800 Subject: [PATCH] cp: im

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

On 2023-02-10 17:27, George Valkov wrote: I’d prefer a timestamp consistent with source. You can get that with 'cp -p' (or with 'cp --preserve=timestamps' etc.). So this is not an issue of whether you can get what you prefer. It's merely an issue about what cp's default behavior is, when the

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

I want to emphasize the fact that we need to get to the bottom of the SEEK_HOLE / SEEK_DATA situation on macOS. Core programs other than 'cp' use these options, and working around the bug in 'cp' won't fix the bug elsewhere. One possibility is to modify Gnulib so that SEEK_HOLE and SEEK_DATA a

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

On 2/10/23 13:46, Pádraig Brady wrote: Maybe. Though POSIX says cp "shall copy" and we're not making a copy, we're making a reflink. If that were an important reason not to clone, then cp should not have made --reflink=auto the default, as clones would not be considered to be copies. Howev

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

does a pass over the file with SEEK_HOLE and SEEK_DATA, so if I understand things correctly it shouldn't run into the problem mentioned there. In other words, that email doesn't appear to explain our current problem.From 9f2c0ab64925a70e287a92e9928100c7cd6368c2 Mon Sep 17 00:00:00 2001 From

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

On 2/10/23 10:58, Pádraig Brady wrote: I was considering "touch"ing the timestamps after also, but it's better to just maintain them as we're pointing to the same data after all. For POSIX conformance we must touch if the user has specified only POSIX options (and has not specified -p). And

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

s pretty much universal now on Apple platforms, this patch is overkill and we should use your much-simpler patch.From bd8c931fade7fcf96c02e4492912f27a2d1c795b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 9 Feb 2023 19:53:59 -0800 Subject: [PATCH] cp: work around APFS bug See <https://b

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 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#61035: [PATCH] cp: improve help regarding ACLs

talk about ACL translation (this can be in the manual rather than the man page as it's reasonably obscure).From 7a8db7dbafc932cb08403b863a1c1edec5d283ca Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 31 Jan 2023 13:52:39 -0800 Subject: [PATCH] doc: document --preserve=mode bet

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 (usage

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

: Paul Eggert Date: Tue, 31 Jan 2023 09:24:43 -0800 Subject: [PATCH] cp,mv: skipping due to -u is success, not failure This reverts the previous change, so that when a file is skipped due to -u, this is not considered a failure. * doc/coreutils.texi: Document this. * src/copy.c (copy_internal): If

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

e attached patch to implement this; comments welcome. In the meantime I'm boldly closing the bug report.From 7a69df88999bedd8e9fccf9f3dfa9ac6907fab66 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 31 Jan 2023 08:46:21 -0800 Subject: [PATCH] cp,ln,mv: when skipping exit with nonzero stat

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 GNU

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 i

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

renaming (e.g., if the destination is not writeable). If we can come up with a better name now's a good time to switch. In the meantime I installed the attached coreutils patch.From 20005ca733e111a61212ee8a6890a54583c55562 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 27 Jan 2023 1

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 he

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 clari

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 --preserve

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

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 somet

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()

change quoted below is applied, but the Gnulib change is not, then ACLs won't be copied. So I don't see how the two changes are independent. Zasláno z Outlooku pro Android<https://aka.ms/AAb9ysg> ____ From: Paul Eggert Sent: Sunday, January 8, 2023 12:53:

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 fo

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#60583: Support for new SI prefixes R, Q

mount of data storage in the world is still less than a yottabyte, and given that we'll need 128-bit integers support all this consistently. Still, the new R and Q prefixes are supported by 'sort' and 'numfmt' as-is.From b7c8754c90a957ef0fa5858cae372be26da69135 Mon Sep 17

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#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 Mc

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#60416: [PATCH] copy: attempt copy offload with sparse files

On 2022-12-30 16:23, Pádraig Brady wrote: I may follow up with a related patch to ensure we _don't_ use copy_file_range with --sparse=never. Not sure it's worth the bother. A file system that would create holes with copy_file_range could also do so with plain 'write', no?

bug#60416: [PATCH] copy: attempt copy offload with sparse files

Thanks, looks good, please install.

bug#60335: du should warn about btrfs

orting the problem. From cfe4af661f9572ad4dbe5b3e01a178e04ff343ae Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 26 Dec 2022 10:34:48 -0800 Subject: [PATCH] doc: improve doc of du with CoW etc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Problem reported by K

bug#60339: tests/cp/proc-short-read.sh may fail due to architecture / case sensitivity assumption

I installed the fix. [Tt][Hh][Aa][Nn][Kk][Ss][.]

bug#60291: chmod a-r does not fail for vfat

On 12/23/22 17:09, Krzysztof Żelechowski wrote: chmod a-r a.txt && stat a.txt Expected: chmod: unsupported permissions Got: -r--r--r-- This is wrong because the command chmod had failed to set the permissions The chmod command is doing the right thing; the problem lies elsewhere. Run "strace

bug#59821: 9.1: du Aborted (corrupt filesystem)

On 12/6/22 23:57, Luke Dashjr wrote: getdents64(3, [{d_ino=1179698, d_off=3802031580503460560, d_reclen=24, d_type=DT_DIR, d_name="."}, {d_ino=1179668, d_off=4580148598467312926, d_reclen=32, d_type=DT_REG, d_name="banlist.json"}, ... This hints at the problem, as it says that "." and its subdi

bug#59821: 9.1: du Aborted (corrupt filesystem)

On 12/6/22 17:02, Luke Dashjr wrote: That was the stack trace in the original report ;) OK. newfstatat(4, "banlist.json", {st_mode=S_IFDIR|0700, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0 openat(4, "banlist.json", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW|O_CLOEXEC|O_DIRECTORY) = 3 newfstat

bug#59821: 9.1: du Aborted (corrupt filesystem)

I don't see any failures in stat-like syscalls there, so it looks like at least the bug you mentioned has mutated (even if it hasn't been fixed...). Who's calling 'abort' and why? You can use GDB to find out.

bug#59821: 9.1: du Aborted (corrupt filesystem)

On 2022-12-04 10:07, Luke Dashjr wrote: Version: sys-apps/coreutils-9.1-r1 (Gentoo) Context: Linux has a long-standing bug which leads to ext4 RAM dishs (zram specifically) getting corrupted randomly. This manifests as various newfstatat calls returning -1 errno=EUCLEAN (Structure needs cleaning

bug#59827: [PATCH] info date to be explicit about the date formats

Thanks for the suggestion. I installed the attached which isn't exactly what you sent but which implements the basic idea.From 5399f2aac4dc8dd4392a1194dc9bdbb2bcc6272c Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 5 Dec 2022 18:42:19 -0800 Subject: [PATCH] doc: improve date -

bug#59732: Problem unable to enter command

On 2022-12-01 01:06, human.id...@simplelogin.com wrote: I think the issue is related to lightdm so it would be better to report the issue to the lightdm developers. Thanks, I'm closing the coreutils bug report.

bug#59732: Problem unable to enter command

On 2022-11-30 14:04, human.idt50--- via GNU coreutils Bug Reports wrote: Hello tty Team, I am using an Arch based distribution. The tty1 screen was opened with the Ctrl+Alt+F1 key combination. When I pressed the Alt+F1 key on this screen, I saw the commands I saw while opening the distribution

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

On 2022-11-19 22:43, Korn Andras wrote: the same file can contain records of different sizes. Reductio ad absurdum: the "optimal" blocksize for reading may in fact depend on the position within the file (and only apply to the next read). This sort of problem exists on traditional devices as wel

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

aximum), cp in the future will surely deal with bigger block sizes. Instead, how about if we stick with GNU's "no arbitrary limits" policy and work around the ZFS bug instead? Something like the attached patch, perhaps?From 551f3f55180669ab0bfd6c5d9e3e0f38cb035172 Mon Sep 17

bug#59262: Dash instead of two hyphens in manual

harder to automate, unfortunately.From 4f43143ab17b3b7646b75838ebcc769854eb7906 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 15 Nov 2022 10:51:47 -0800 Subject: [PATCH 1/2] maint: fix cfg.mk comment * cfg.mk (sc_texi_long_option_escaped): Fix comment. --- cfg.mk | 5 + 1 file changed, 1

bug#59262: Dash instead of two hyphens in manual

Thanks for reporting that. Fixed by installing the attached. This should propagate to the web pages after the next release.From b73888b12caa359c93d05aa7ff7c3a66a74b5f7b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 14 Nov 2022 19:00:06 -0800 Subject: [PATCH 1/2] build: update gnulib

bug#58881: Question: df Size

On 2022-10-29 12:31, linux wrote: Can you write in " man " why df shows different result than lsblk ? Not easily, as that depends on the internals of the filesystem, which is out of coreutils's control and/or view. df is simply repeating what the kernel reports about the filesystem. If the

bug#58599: `date -d $(date)` error for non en_* locale

On 10/17/22 07:44, Ruslan Kovtun wrote: According to "do one thing and do it well" and to the fact of '-d/--date' option existence, `date` should be able to parse its default output in any locale. Patches would be welcome. Good luck getting it to work, though. Many date formats are ambiguous,

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