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

On Friday, May 5, 2023 12:29:16 AM CEST Pádraig Brady wrote: > 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

Re: coreutils-9.3 released [stable]

On Tuesday, April 18, 2023 5:16:29 PM CEST Pádraig Brady wrote: > This is to announce coreutils-9.3, a stable release. > This is a bug fix release coming about 4 weeks after the 9.2 release. > See the NEWS below for a summary of changes. Thanks! I had to revert the following gnulib commit to be

Re: tee: not checking for EAGAIN or EWOULDBLOCK causing missing output to terminal

On Tuesday, March 7, 2023 8:01:59 PM CET Pádraig Brady wrote: > On 07/03/2023 14:39, Kamil Dudka wrote: > > On Tuesday, March 7, 2023 2:28:05 AM CET Pádraig Brady wrote: > >> On 25/07/2019 11:59, Kamil Dudka wrote: > >>> I see two major issues with the patch: > &g

Re: tee: not checking for EAGAIN or EWOULDBLOCK causing missing output to terminal

On Tuesday, March 7, 2023 2:28:05 AM CET Pádraig Brady wrote: > On 25/07/2019 11:59, Kamil Dudka wrote: > > I see two major issues with the patch: > > > > 1. If the file descriptor operates in non-blocking mode and it starts > > to return EAGAIN, tee will busy-lo

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

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

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

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

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

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

Re: [PATCH] yes: Remove memory leak on buf memory

On Friday, November 18, 2022 9:45:23 AM CET Kaz Kylheku wrote: > On 2022-11-17 14:21, Alireza Arzehgar wrote: > > From a4edebe5bafb8bf789cf5e9c807375c9bcdfab4e Mon Sep 17 00:00:00 2001 > > From: alireza > > Date: Fri, 18 Nov 2022 01:33:10 +0330 > > Subject: [PATCH] yes: Remove memory leak on buf

Re: new snapshot available: coreutils-9.0.193-54bec.tar.xz

On Monday, April 11, 2022 2:59:10 PM CEST Pádraig Brady wrote: > Your message was unintentionally dropped from the list. > Thanks for taking the extra time to mail this directly. > > Your analysis is correct, but setting LC_MESSAGES=C might not work in all > cases. We had issues previously with

bug#54286: [PATCH] Fix ls -l triggering automounts.

On Monday, March 7, 2022 3:26:27 PM CET Pádraig Brady wrote: > Updated patch for ls attached as per discussion. > Added a NEWS entry. Works as expected. Thank you both! Kamil

bug#54287: [PATCH] Fix stat command triggering automount.

On Monday, March 7, 2022 3:40:25 PM CET Pádraig Brady wrote: > New stat patch attached to apply AT_NO_AUTOMOUNT > unless --cached=never is specified. > > See https://bugs.gnu.org/54286 for more general discussion. > Marking this as done. > > cheers, > Pádraig Works as expected. Thank you both!

Re: BUG Report: CentOS within a Docker Image

On Thursday, December 23, 2021 1:18:08 PM CET Daniel Creager wrote: > When I attempted to run: > tail -f > > on my CentOS image within Docker I received the following: > > tail: unrecognized file system type 0x794c7630 for > 'GCManager.20211223.0035.STD.log'. please report this to >

bug#52481: chown of coreutils may delete the suid of file

On Tuesday, December 14, 2021 3:49:37 AM CET 21625039 wrote: > I encountered a problem with chown on my fedora34 as the version of > coreutils is 8.32. > > > > The reproduce process could see the steps blow: > > [root@fedora ~]# ll test.txt > > -rw-r--r--. 1 root root 0 Dec 13 21:13 test.txt

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

On Friday, November 26, 2021 12:10:36 AM CET 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", the least the command could do is put > these in the correct order. > > > it is a one-time effort to learn the order >

Re: Suggest on "ln"

On Monday, July 19, 2021 2:29:18 AM CEST James Lu wrote: > "ln" should write a warning to stderr if the source file doesn't exist. ln writes an error message to stderr if the source file does not exist: $ mkdir new-dir $ cd new-dir $ ln does-not-exist target ln: failed to access

bug#49298: [PATCH] df: do not print duplicated entires with NFS and bind mounts

As originally reported in , df invoked without -a printed duplicated entries for NFS mounts of bind mounts. This is a regression from commit v8.25-54-g1c17f61ef99, which introduced the use of a hash table. The proposed patch makes sure that the devlist entry

bug#49239: Unexpected results with sort -V

On Monday, June 28, 2021 6:52:14 PM CEST Michael Debertol wrote: > I was trying to say that the regex is not followed in two cases: > > - when there are two dots followed by [A-Za-z~], the second dot should > be matched, but it is not. > > An example is "foo..a": In this case ".a" should be

bug#49239: Unexpected results with sort -V

On Sunday, June 27, 2021 12:04:53 AM CEST Michael wrote: > Hi, > I found some unexpected results with sort -V. I hope this is the correct > place to send a bug report to [1]. > They are caused by a bug in filevercmp inside gnulib, specifically in the > function match_suffix. > I assume it should,

bug#49209: coreutils: stack out-of-bounds write in tail --follow

On Sunday, June 27, 2021 3:47:46 AM CEST Paul Eggert wrote: > When looking into this I decided it was cleaner to fix coreutils by > using 'poll' instead of 'select', as Kamil suggested. I installed the > attached patches to do that. The last patch fixes the bug. This works for me. Thank you for

bug#49209: coreutils: stack out-of-bounds write in tail --follow

On Thursday, June 24, 2021 4:50:25 PM CEST Pádraig Brady wrote: > Note the number of descriptors select() is waiting on in independent of the > number of files. We should be able to inotify_init() earlier in the process > to avoid this issue. I'll have a look. Good idea! This could make it work

bug#49209: coreutils: stack out-of-bounds write in tail --follow

Hello, As originally reported by Stepan Broz (CC'd), tail --follow crashes when it is given too many files to follow, and ulimit -n is set to >1024. FD_SET(wd, ) in tail_forever_inotify() writes beyond the stack-allocated variable in case wd >= FD_SETSIZE. Minimal example: # mkdir dir # cd

bug#48036: [PATCH] copy: do not refuse to copy a swap file

From: Zorro Lang * src/copy.c (sparse_copy): Fallback to read() if copy_file_range() fails with ETXTBSY. Otherwise it would be impossible to copy files that are being used as swap. This used to work before introducing the support for copy_file_range() in coreutils. --- src/copy.c | 2 +- 1

bug#47383: [PATCH 2/2] ln: fix memory leaks in do_link()

On Thursday, March 25, 2021 5:19:56 PM CET Paul Eggert wrote: > Thanks, I installed that. I then changed "free(" to "free (" as per GNU > style. Thank you for incorporating both the patches. Kamil

bug#47384: [PATCH 1/2] hostname: fix a memory leak with -Dlint

On Thursday, March 25, 2021 5:09:44 PM CET Paul Eggert wrote: > On 3/25/21 9:08 AM, Kamil Dudka wrote: > > Wasn't that exactly what -Dlint was for when we discussed it the last > > time? > > Sorry, don't recall the last time. I meant this thread on bug-gnulib ML:

bug#47384: [PATCH 1/2] hostname: fix a memory leak with -Dlint

On Thursday, March 25, 2021 4:56:15 PM CET Paul Eggert wrote: > On 3/25/21 3:57 AM, Kamil Dudka wrote: > > +#ifdef lint > > + free(hostname); > > +#endif > > Let's not do this one. The program is about to exit so there's no need > to free, and any static-chec

bug#47383: [PATCH 2/2] ln: fix memory leaks in do_link()

* src/ln.c (do_link): Free memory allocated by convert_abs_rel() on all code paths. --- src/ln.c | 19 +-- 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/src/ln.c b/src/ln.c index e79ca5e7ade..368b109daf0 100644 --- a/src/ln.c +++ b/src/ln.c @@ -229,14 +229,14 @@

bug#47384: [PATCH 1/2] hostname: fix a memory leak with -Dlint

* src/hostname.c (main): Free allocated memory when compiled with -Dlint. --- src/hostname.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/hostname.c b/src/hostname.c index 7d13575d4e9..8ec9aad4d34 100644 --- a/src/hostname.c +++ b/src/hostname.c @@ -104,6 +104,9 @@ main (int argc,

Re: ls is broken, what's next cd?

On Tuesday, February 6, 2018 4:02:19 PM CET Kamil Dudka wrote: > On Tuesday, February 6, 2018 3:31:11 PM CET Eric Blake wrote: > > The change has already been made. Even if we now revert it, users still > > have to deal with versions in the wild that have the change. > >

bug#46613: [PATCH] stat: add support for the exfat file system

* src/stat.c (human_fstype): Add case for the 'exfat' file system type. * NEWS: Mention the Improvement. Bug: https://bugzilla.redhat.com/1921427 --- NEWS | 2 +- src/stat.c | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 79bb25e860..08a58d56a6

Re: [PATCH] selinux-h: add stubs for selabel_open etc.

On Monday, November 23, 2020 10:49:57 AM CET Paul Eggert wrote: > Thanks, I think I see the problem. I installed the attached to try to fix it. Yes, this made the test-suite green again. Thanks! Kamil

Re: [PATCH] selinux-h: add stubs for selabel_open etc.

On Sunday, November 22, 2020 7:08:44 PM CET Pádraig Brady wrote: > > It seems selabel_lookup requires absolute paths. > > Reinstating that code with the attached, > > gets all tests to pass here on Fedora 32 > > with selinux enabled. > > Non leaky version attached. > > cheers, > Pádraig Thanks

Re: [PATCH] selinux-h: add stubs for selabel_open etc.

On Sunday, November 22, 2020 3:45:22 AM CET Paul Eggert wrote: > Yes, it's looking like great minds think alike. > > The coreutils patch I had prepared is fancier than yours, though, as it > caches the result of selabel_open and this should yield better performance. > > I don't use SELinux

bug#44308: md5sum (and other *sum utils) path dependent output

On Thursday, October 29, 2020 11:41:03 AM CET Alessandro Forghieri wrote: > Greetings. > > Just stumbled upon this: > > *# md5sum > ./Development/rss/rss/STAGING/BATTITI_del_27_11_2016_-_Battiti_Live:_Arsene_ > Duevi\\Roberto_Zanisi.mp3 \d41d8cd98f00b204e9800998ecf8427e >

bug#44235: [PATCH] dd: drop old workaround for lseek() bug in Linux kernel

On Monday, October 26, 2020 2:11:59 PM CET Pádraig Brady wrote: > On 26/10/2020 10:44, Kamil Dudka wrote: > > The workaround triggers warnings with new kernel versions in case > > a user does not have sufficient privileges for the MTIOCGET ioctl. > > > > * src/dd.c (sk

bug#44235: [PATCH] dd: drop old workaround for lseek() bug in Linux kernel

The workaround triggers warnings with new kernel versions in case a user does not have sufficient privileges for the MTIOCGET ioctl. * src/dd.c (skip_via_lseek): Drop wrapper function no longer needed. (skip): Use lseek() directly. (advance_input_after_read_error): Use lseek() directly.

bug#43998: 8.32: test suite is failing

On Wednesday, October 14, 2020 11:43:08 PM CEST Tomasz Kłoczko wrote: > Hi, > > Two units are failing in my build env: > > FAIL: tests/cp/fiemap-FMR > = > > ==420069== Syscall param ioctl(generic) points to unaddressable byte(s) > ==420069==at 0x49B94AB: ioctl (in

Re: Patchset pertaining to --si option of df, du, ls

On Tuesday, September 8, 2020 6:27:02 PM CEST Glenn Golden wrote: > The patchset brings the behavior into accordance with the behavior > documented in Section 2.3. I would prefer to fix it the other way around: bring the documentation into accordance with the current behavior. All existing

Re: Is --enable-single-binary=symlinks a problem for a distribution?

On Thursday, August 27, 2020 1:53:56 AM CEST Pádraig Brady wrote: > On 26/08/2020 17:52, Bernhard Voelker wrote: > > Hi Padraig et al, > > > > in downstream openSUSE, we're considering to switch to building with > > > >./configure --enable-single-binary=symlinks ... > > > > per default.

bug#37702: Suggestion for 'df' utility

On Sunday, May 31, 2020 2:49:24 PM CEST Pádraig Brady wrote: > On 31/05/2020 10:36, Bernhard Voelker wrote: > > What about to start with this? > > > >$ GIT_PAGER= git -C gnulib diff > >diff --git a/lib/mountlist.c b/lib/mountlist.c > >index 7abe0248e..5f6249dec 100644 > >---

bug#41563: Possible bug with 'sort -Vr' version sorting

On Thursday, May 28, 2020 11:02:43 AM CEST Erik Auerswald wrote: > On Thu, May 28, 2020 at 08:48:16AM +0200, Kamil Dudka wrote: > > It is the underscore in the .x86_64 suffix what breaks the version compare > > algorithm. If you replace the underscore by an alphabetic characte

bug#41563: Possible bug with 'sort -Vr' version sorting

On Wednesday, May 27, 2020 2:07:32 PM CEST Danie de Jager via GNU coreutils Bug Reports wrote: > Hi, > > I use sort -Vr to sort version numbers. I noticed this discrepancy on > the latest kernel version from Centos 7.8. > > command to get output: > # ls -t /boot/vmlinuz-* | sed

Re: Simpler name for --no-clobber option

On Wednesday, March 11, 2020 3:37:06 PM CET Leslie S Satenstein via GNU coreutils General Discussion wrote: > Just saw this message. for --no-clobber, would --no-replace > suffice? the latter could also be shortened to --nr. I am afraid that you are 11 years late to this

bug#39929: coreutils-8.32 fails to build on aarch64

On Thursday, March 5, 2020 6:39:23 PM CET Pádraig Brady wrote: > On 05/03/2020 16:21, Kamil Dudka wrote: > > While trying to build coreutils-8.32 for Fedora on aarch64, I got the > > following compilation failure: > > > > ../src/ls.c: In function 'print_dir': >

bug#39929: coreutils-8.32 fails to build on aarch64

While trying to build coreutils-8.32 for Fedora on aarch64, I got the following compilation failure: ../src/ls.c: In function 'print_dir': ../src/ls.c:3026:24: error: 'SYS_getdents' undeclared (first use in this function); did you mean 'SYS_getdents64'? 3026 | if (syscall

bug#39485: [PATCH] make tests/cp/preserve-gid work with single binary

On Saturday, February 8, 2020 12:53:52 PM CET Pádraig Brady wrote: > Considering --enable-single-binary-exceptions may exclude cp, > and also that coreutils(1) may be compiled during > non --enable-single-binary build when building > all programs for `make syntax-check` etc. > we should add an

bug#39485: [PATCH] make tests/cp/preserve-gid work with single binary

* tests/cp/preserve-gid.sh: If configured with --enable-single-binary copy the coreutils single binary, instead of the cp one-line launcher. Bug: https://bugzilla.redhat.com/1800597 --- tests/cp/preserve-gid.sh | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git

bug#39357: tests/cp/proc-short-read.sh fails in modern build environment

On Tuesday, February 4, 2020 1:45:06 AM CET Pádraig Brady wrote: > On 30/01/2020 13:53, Kamil Dudka wrote: > > tests/cp/proc-short-read.sh expects that a pair of subsequent reads from > > /proc/kallsyms will always return the same content. This does not seem to > > be a saf

bug#39357: tests/cp/proc-short-read.sh fails in modern build environment

tests/cp/proc-short-read.sh expects that a pair of subsequent reads from /proc/kallsyms will always return the same content. This does not seem to be a safe assumption any more. The test has started to fail in our build environment. I am not sure how to fix the test. We could probably make it

Re: [PATCH] chcon: do not validte security context if SElinux is disabled

On Monday, December 2, 2019 2:18:39 PM CET Pádraig Brady wrote: > On 02/12/2019 13:02, Kamil Dudka wrote: > > * src/chcon.c (main): Skip call of security_check_context() > > in case SELinux is disabled to avoid unnecessary failure. > > > > Bug: https://bugzilla.redhat

[PATCH] chcon: do not validte security context if SElinux is disabled

* src/chcon.c (main): Skip call of security_check_context() in case SELinux is disabled to avoid unnecessary failure. Bug: https://bugzilla.redhat.com/1777831 --- src/chcon.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/chcon.c b/src/chcon.c index

bug#37702: Suggestion for 'df' utility

On Monday, October 14, 2019 8:06:47 AM CEST Paul Eggert wrote: > On 10/13/19 3:00 PM, Assaf Gordon wrote: > > I'm not sure if it's easy to find a set of criteria > > that would work well while having minimal unexpected side effects of > > hiding > > entries people in other systems do expect to

Re: tee: not checking for EAGAIN or EWOULDBLOCK causing missing output to terminal

I see two major issues with the patch: 1. If the file descriptor operates in non-blocking mode and it starts to return EAGAIN, tee will busy-loop (consume 100% CPU) until the file descriptor becomes ready again. 2. If fwrite() fails with EAGAIN, you cannot repeat the call with the same

bug#35531: problem with ls in coreutils

On Friday, May 3, 2019 5:56:35 PM CEST Viktors Berstis wrote: > I don't think the problem has anything to do with sorting or -U1. It was unclear what you meant by "the problem" so I pointed out the only inefficiency that was immediately obvious to me. > When ls is taking over 5 minutes for

bug#35531: problem with ls in coreutils

On Friday, May 3, 2019 5:43:20 AM CEST Viktors Berstis wrote: > I downloaded it from > https://sourceforge.net/projects/gnuwin32/files/coreutils/5.3.0/coreutils-5. > 3.0.exe/download The help said "Report bugs to " > which is what I did. The build is so old that I suspect none of the > original

bug#35531: problem with ls in coreutils

On Thursday, May 2, 2019 12:03:31 AM CEST Viktors Berstis wrote: > When running "ls" or "ls -U" on a windows directory containing 5 > files, ls takes forever. Something seems to be highly inefficient in there. Could you please try it with ls -U -1? Kamil > This is for the 64 bit version

Re: cut -d fails when using a multi-byte delimiter

On Wednesday, March 27, 2019 9:04:06 AM CET Tim Rühsen wrote: > Hi Eric, > > I assume that you submitted your patches to this mailing list See the big thread with subject "Multibyte support for sort, uniq, join, tr, cut, paste, expand, unexpand, fmt, fold, and pr" on this mailing list. > as

bug#34856: [PATCH] *sum --help: add note about binary/text mode

On Monday, March 18, 2019 9:11:59 AM CET Bernhard Voelker wrote: > On 3/14/19 1:48 PM, Kamil Dudka wrote: > > +Note: There is no difference between binary mode and text mode on GNU > > systems.\ > Thanks for the patch - I see this is a downstream patch in Fedora since > sev

bug#33646: [PATCH] doc: improve wording of the --kibibytes option description

On Friday, March 15, 2019 7:30:55 PM CET Assaf Gordon wrote: > Pushed here: > https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=6bd78f27fdc2df89b > 1219921c6f5735885f15e37 > > -assaf Thanks! Kamil

bug#33646: [PATCH] doc: improve wording of the --kibibytes option description

On Friday, January 18, 2019 8:26:18 AM CET Assaf Gordon wrote: > Hello, > > On 2018-12-06 6:32 a.m., Kamil Dudka wrote: > > Bug: https://bugzilla.redhat.com/1527391 > > --- > > > > doc/coreutils.texi | 8 +--- > > 1 file changed, 5 insertions(+), 3

bug#34856: [PATCH] *sum --help: add note about binary/text mode

* src/md5sum.c (usage): Make it clear that there is no difference between binary mode and text mode on GNU systems. Bug: https://bugzilla.redhat.com/406981 Bug: https://bugzilla.redhat.com/1688740 --- src/md5sum.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

Re: new snapshot available: coreutils-8.30.79-efa3e.tar.xz

On Monday, March 4, 2019 11:18:19 AM CET Pádraig Brady wrote: > We plan to release coreutils-8.31 in the coming week > so any testing you can do on various different systems between now and then > would be most welcome. > > -- > > You can download the

bug#33644: [PATCH] cp --preserve=xattr: preserve NFSv4 ACL extended attributes

On Sunday, March 3, 2019 3:07:53 AM CET Pádraig Brady wrote: > So attr_copy_file() copies all except those defined in /etc/xattr.conf ... which is, however, not how xattr.conf is currently documented: # /etc/xattr.conf # # Format: # # # Actions: # permissions -

bug#33644: [PATCH] cp --preserve=xattr: preserve NFSv4 ACL extended attributes

On Monday, February 11, 2019 7:30:42 PM CET Pádraig Brady wrote: > On 11/02/19 03:50, Kamil Dudka wrote: > > I think that the information in xattr.conf is correct. system.nfs4_acl is > > really an attribute one wants to copy when trying to preserve permissions. > > Righ

bug#33644: [PATCH] cp --preserve=xattr: preserve NFSv4 ACL extended attributes

On Monday, February 11, 2019 6:07:18 AM CET Pádraig Brady wrote: > On 06/12/18 05:08, Kamil Dudka wrote: > > ... which cannot be preserved by other means > > > > Bug: https://bugzilla.redhat.com/1031423#c4 > > --- > > > > src/copy.c | 22 +-

bug#33646: [PATCH] doc: improve wording of the --kibibytes option description

On Friday, January 18, 2019 8:26:18 AM CET Assaf Gordon wrote: > Hello, > > On 2018-12-06 6:32 a.m., Kamil Dudka wrote: > > Bug: https://bugzilla.redhat.com/1527391 > > --- > > > > doc/coreutils.texi | 8 +--- > > 1 file changed, 5 insertions(+), 3

bug#33646: [PATCH] doc: improve wording of the --kibibytes option description

Bug: https://bugzilla.redhat.com/1527391 --- doc/coreutils.texi | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/doc/coreutils.texi b/doc/coreutils.texi index f8339d73f..e93fe71a0 100644 --- a/doc/coreutils.texi +++ b/doc/coreutils.texi @@ -7975,9 +7975,11 @@ Append

bug#33644: [PATCH] cp --preserve=xattr: preserve NFSv4 ACL extended attributes

... which cannot be preserved by other means Bug: https://bugzilla.redhat.com/1031423#c4 --- src/copy.c | 22 +- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/src/copy.c b/src/copy.c index 3221b9997..754c5e1aa 100644 --- a/src/copy.c +++ b/src/copy.c @@

bug#33622: coreutils v. 8.30 – Tail prints the first row in 'tail -n '

On Wednesday, December 5, 2018 11:51:09 AM CET Ricky Tigg wrote: > OS: *Fedora*. Component: coreutils.x86_64 8.30-6.fc29 @System > > Tail prints the first row in 'tail -n ' > > Command executed: > $ dnf repoquery --requires bash --recursive --resolve | grep -E > '.x86_64$|.noarch$' | tail -n 1 >

bug#33523: broken URL in install(1) man page

On Tuesday, November 27, 2018 11:21:03 PM CET Bernhard Voelker wrote: > On 11/27/18 5:28 PM, Kamil Dudka wrote: > > The SEE ALSO section of install(1) man page contains a broken URL: > > Full documentation at: > > <https://www.gnu.org/software/coreutils/install&g

bug#33523: broken URL in install(1) man page

The SEE ALSO section of install(1) man page contains a broken URL: Full documentation at: The URL returns: 404 - Page Not Found I suspect it is caused by the build-time rename ginstall -> install. If one substitutes 'install' by

bug#33287: [PATCH] sync: add missing brackets in sync_arg()

On Wednesday, November 7, 2018 12:33:45 AM CET Bernhard Voelker wrote: > On 11/6/18 7:35 PM, Paul Eggert wrote: > > Thanks, I installed that and am closing the bug report. > > That was a real bug, i.e., not only a resource leak, wasn't it? > > If the calling user has -r+w permissions on the

bug#33287: [PATCH] sync: add missing brackets in sync_arg()

Detected by Coverity Analysis: Error: RESOURCE_LEAK (CWE-772): coreutils-8.30/src/sync.c:112: open_fn: Returning handle opened by "open". coreutils-8.30/src/sync.c:112: var_assign: Assigning: "fd" = handle returned from "open(file, 2049)". coreutils-8.30/src/sync.c:115: leaked_handle: Handle

Re: [PATCH v3] tee: handle EAGAIN returned from fwrite/fclose()

On Monday, November 5, 2018 12:54:25 PM CET Pádraig Brady wrote: > On 01/11/18 07:39, Kamil Dudka wrote: > > On Tuesday, September 11, 2018 3:05:20 PM CET Kamil Dudka wrote: > >> 'tee' expected the output file descriptors to operate in blocking mode > >> but this assu

Re: [PATCH v3] tee: handle EAGAIN returned from fwrite/fclose()

On Tuesday, September 11, 2018 3:05:20 PM CET Kamil Dudka wrote: > 'tee' expected the output file descriptors to operate in blocking mode > but this assumption might be invalidated by other programs connected to > the same terminal, as in the following example: > > $ telnet ...

[PATCH v3] tee: handle EAGAIN returned from fwrite/fclose()

'tee' expected the output file descriptors to operate in blocking mode but this assumption might be invalidated by other programs connected to the same terminal, as in the following example: $ telnet ... | tee log_file telnet calls ioctl(stdin, FIONBIO, [1]), which causes the O_NONBLOCK flag to

Re: [PATCH] tee: recover from EAGAIN returned from fwrite()

On Tuesday, September 11, 2018 6:49:09 AM CEST Pádraig Brady wrote: > On 10/09/18 09:38, Kamil Dudka wrote: > > On Friday, September 7, 2018 5:21:04 AM CEST Pádraig Brady wrote: > >> Also would `cat | telnet ... | tee blah` be a workaround? > > > > The above comman

Re: [PATCH] tee: recover from EAGAIN returned from fwrite()

On Friday, September 7, 2018 5:21:04 AM CEST Pádraig Brady wrote: > On 06/09/18 07:28, Kamil Dudka wrote: > > tee expects the output descriptors to operate in blocking mode but this > > assumption might be invalidated by other programs connected to the same > > terminal

[PATCH] tee: recover from EAGAIN returned from fwrite()

tee expects the output descriptors to operate in blocking mode but this assumption might be invalidated by other programs connected to the same terminal, as in the following example: $ telnet ... | tee log_file telnet calls ioctl(stdin, FIONBIO, [1]), which causes the O_NONBLOCK flag to be set

Re: new snapshot available: coreutils-8.29.64-1755f.tar.xz

On Sunday, July 1, 2018 3:37:36 AM CEST Pádraig Brady wrote: > On 28/06/18 02:56, Kamil Dudka wrote: > > On Thursday, June 28, 2018 5:59:13 AM CEST Pádraig Brady wrote: > >> Note one should define 'lint' when running static analysis, > >> to avoid false positives. &g

Re: new snapshot available: coreutils-8.29.64-1755f.tar.xz

On Thursday, June 28, 2018 5:59:13 AM CEST Pádraig Brady wrote: > On 27/06/18 06:36, Kamil Dudka wrote: > > I am getting many warnings from static analyzers about uses of > > uninitialized stat buffer in the copy_internal() function. I think it is > > related to the optimiz

Re: new snapshot available: coreutils-8.29.64-1755f.tar.xz

On Wednesday, June 27, 2018 12:02:07 PM CEST Pádraig Brady wrote: > We plan to release coreutils-8.30 in the coming week > so any testing you can do on various different systems between now and then > would be most welcome. > > -- > > You can download the

bug#31644: tests/ls/abmon-align does not work today (May 29th)

On Tuesday, May 29, 2018 7:16:43 PM CEST Pádraig Brady wrote: > On 29/05/18 09:16, Kamil Dudka wrote: > > Re-posting with a fresh subject. debbugs.gnu.org rejected my original > > post > > because the original bug has been closed and has received no comments for

bug#31644: tests/ls/abmon-align does not work today (May 29th)

Re-posting with a fresh subject. debbugs.gnu.org rejected my original post because the original bug has been closed and has received no comments for more than 28 days: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30814 On Wednesday, March 14, 2018 7:40:31 PM CEST Pádraig Brady wrote: >

bug#31439: [PATCH] fts: avoid a memory leak edge case

On Monday, May 14, 2018 3:51:02 AM CEST Pádraig Brady wrote: > @@ -122,9 +139,10 @@ main (void) > perror_exit (base, 6); >while ((e = fts_read (ftsp))) > needles_seen += strcmp (e->fts_name, "needle") == 0; > - fflush (stdout); >if (errno) > perror_exit ("fts_read", 7); > +

bug#30907: mv return value.

On Friday, March 23, 2018 2:00:01 PM CET Eric Blake wrote: > I don't know if mv exposes RENAME_NOREPLACE semantics yet, but it should > be taught to do so, where such semantics are available. mv was recently patched to use renameat2(..., RENAME_NOREPLACE):

Re: Multibyte support for sort, uniq, join, tr, cut, paste, expand, unexpand, fmt, fold, and pr

On Tuesday, March 20, 2018 11:18:23 PM CET Assaf Gordon wrote: > Two things for later (not critical for now): > to make review easier, it's recommended to combine all commits that > relate to a single program > into one commit. This is called "squash" in git (see: >

Re: [SUGGESTION] nohup_${PID}.out

On Monday, February 19, 2018 12:30:33 AM CET Boruch Baum wrote: > On 2018-02-19 00:14, Bernhard Voelker wrote: > > Have a nice day, > > Berny > > Thank you for the kind wishes. I hope the list will continue to consider > the entirety of the suggestions in my post. As far as I can tell, all your

bug#29961: [PATCH] mv -n: do not overwrite the destination

On Wednesday, January 10, 2018 9:53:07 AM CET Paul Eggert wrote: > No further comment, so I installed the proposed patches and I'm closing this > bug report. Sorry. There were just too many changes in your patches for me to review them quickly enough (and most of the changes were unrelated to my

bug#29961: [PATCH] mv -n: do not overwrite the destination

On Friday, January 5, 2018 4:29:55 PM CET Pádraig Brady wrote: > Thanks to both of you. > The approaches can be summarized as: > > Orig: > - > stat() => ENOENT > > rename() may clobber file > > Kamil's: > - > stat() => ENOENT > >

bug#29961: [PATCH] mv -n: do not overwrite the destination

On Friday, January 5, 2018 2:00:52 AM CET Paul Eggert wrote: > On 01/04/2018 03:01 AM, Kamil Dudka wrote: > > On Thursday, January 4, 2018 10:48:56 AM CET Paul Eggert wrote: > >> Kamil Dudka wrote: > >>> - if (rename (src_name, dst_name) == 0) > >>>

bug#29961: [PATCH] mv -n: do not overwrite the destination

On Thursday, January 4, 2018 10:48:56 AM CET Paul Eggert wrote: > Kamil Dudka wrote: > > - if (rename (src_name, dst_name) == 0) > > + int flags = 0; > > + if (x->interactive == I_ALWAYS_NO) > > +/* do not replace DST_NAME if it wa

bug#29961: [PATCH] mv -n: do not overwrite the destination

... if it is created by another process after mv has checked its non-existence. * src/copy.c (copy_internal): Use renameat2 (..., RENAME_NOREPLACE) if called by mv -n. If it fails with EEXIST in that case, pretend successful rename as if the existing destination file was detected by the

bug#29961: [PATCH] mv: document the missing atomicity of 'mv -n'

On Wednesday, January 3, 2018 4:08:51 PM CET Pádraig Brady wrote: > Eep, Seems like we should use RENAME_NOREPLACE in this case, > rather than document the caveat? Thanks for the suggestion! I will give it a try... Kamil > This is already used in shred. > > cheers, > Pádraig

bug#29961: [PATCH] mv: document the missing atomicity of 'mv -n'

* src/mv.c (usage): Add note about the missing atomicity of 'mv -n'. * doc/coreutils.texi (mv invocation): Likewise. --- doc/coreutils.texi | 3 +++ src/mv.c | 2 ++ 2 files changed, 5 insertions(+) diff --git a/doc/coreutils.texi b/doc/coreutils.texi index 3fa083085..e7ca6a737 100644

Re: new snapshot available: coreutils-8.28.61-70c84

On Thursday, December 21, 2017 4:51:10 PM CET Pádraig Brady wrote: > We plan to release coreutils-8.29 in the next few days, > so any testing you can do on various different systems between now and then > would be most welcome. > > -- > > You can download the

bug#29563: [PATCH] doc: fix default QUOTING_STYLE for %N format of stat(1)

* doc/coreutils.texi (stat invocation): The default value of QUOTING_STYLE for the %N format of 'stat --printf' is 'shell-escape-always'. Reported by Christian Groessler at https://bugzilla.redhat.com/1520399#c3 --- doc/coreutils.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH] expr: plug a memory leak in eval6()

* src/expr.c (eval6): Free memory allocated by mbs_logical_substr(). Introduced in v8.27-47-ga9f2be5. Detected by Coverity Analysis: Error: RESOURCE_LEAK: src/expr.c:849: alloc_fn: Storage is returned from allocation function "mbs_logical_substr". src/expr.c:275:5: alloc_fn: Storage is

bug#24541: runcon tty hijacking via TIOCSTI ioctl

On Monday, August 28, 2017 11:51:12 AM CEST Pádraig Brady wrote: > On 29/09/16 08:15, Bernhard Voelker wrote: > > On 09/26/2016 05:53 PM, Paul Eggert wrote: > >>> "I don't think we need to fix this for runcon, as it isn't as > >>> sandboxing tool like sandbox, and the loss of job control would

bug#28120: [PATCH] ptx: fix a possible crash caused by integer overflow

On Thursday, August 17, 2017 12:14:05 Paul Eggert wrote: > On 08/17/2017 04:40 AM, Kamil Dudka wrote: > > -typedef short int DELTA; /* to hold displacement within one context */ > > +typedef int DELTA; /* to hold displacement within one context */ > > Thanks for t

bug#28120: [PATCH] ptx: fix a possible crash caused by integer overflow

The crash might not be reproducible in all environments but I was able to observe invalid reads by valgrind while running ptx on the reproducer for : % curl -s 'https://bugzilla.redhat.com/attachment.cgi?id=1314625' | gzip -cd | valgrind ptx > /dev/null

  1   2   3   >