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

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.

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 happening

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!

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 >

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 s

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 match

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, a

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 t

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 i

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, &rfd) 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 fil

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

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 sta

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 @@ do

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, ch

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 100644

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 > ./Development/rss/rss/ST

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. Reported-

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 /us

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 > >--- a/lib/

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 character,

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 "s/\/boot\/vmlinu

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

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 extr

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 a/tests/cp/pr

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 u

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 see.

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 s

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 pla

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 bui

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 a/src/md5sum.

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

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. > > Right.

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 @sam

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 @@ -640,6

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 'ginstal

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 file,

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 vari

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: > Given

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): http://git.savannah.gnu.org/cgit/coreuti

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 preceding

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 -

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

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 like

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 ==4288

bug#25052: [PATCH] install, mkdir: fix handling of -DZ and -pZ, respectively

On Monday, November 28, 2016 16:11:34 Pádraig Brady wrote: > On 28/11/16 15:21, Kamil Dudka wrote: > > ... in case two or more directories nested in each other are created and > > each of them defaults to a different SELinux context. > > > > * src/install.c (m

bug#25052: [PATCH] install, mkdir: fix handling of -DZ and -pZ, respectively

... in case two or more directories nested in each other are created and each of them defaults to a different SELinux context. * src/install.c (make_ancestor): When calling defaultcon(), give it the same path that is given to mkdir(). The other path is not always valid wrt. current working direct

bug#24232: [PATCH] ls: postpone installation of signal handlers

On Tuesday, September 06, 2016 19:07:13 Pádraig Brady wrote: > On 06/09/16 18:18, Jim Meyering wrote: > > On Tue, Sep 6, 2016 at 10:05 AM, Paul Eggert wrote: > >> On 09/06/2016 08:59 AM, Pádraig Brady wrote: > >>> Will push later. > >> > >> Before pushing, can you please change the name of "sigs"

bug#24232: [PATCH] ls: postpone installation of signal handlers

... until they are actually needed. That is right before the first escape sequence is printed to a terminal. * src/ls.c (sigs): Moved from main() to global scope to make it available in put_indicator(), too. Renamed to prevent identifier clashes with parameters of subsequent function definitions

bug#24232: ls --color cannot be interrupted by a signal

On Monday, August 15, 2016 15:55:13 Pádraig Brady wrote: > The signal catching functionality originated trying to restore terminal > color: > http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v4.5.3-89-g854 > 9068 > > That was adjusted to only outputting reset chars once for multiple si

bug#24232: ls --color cannot be interrupted by a signal

If 'ls --color' outputs to a terminal and a syscall blocks (e.g. while reading a directory from unresponsive network file system), it cannot be interrupted by a signal. This seems to be caused by the code of ls, which sets the SA_RESTART flag on terminating signals. A possible solution would b

bug#24015: [PATCH v2 1/3] sort: deduplicate code for traversing numbers

On Monday, July 18, 2016 22:28:56 Pádraig Brady wrote: > On 18/07/16 22:07, Pádraig Brady wrote: > > Excellent. I'll push all three patches. > > > > I'll adjust the first summary like s/sort:/maint: sort.c:/ > > since there is no functionality change > > > > I'll also add the check for the sv_SE

bug#24015: [PATCH v2 3/3] sort: with -h, disallow thousands separator between number and unit

* src/sort.c (traverse_raw_number): Accept thousands separator only if it is immediately followed by a digit. * tests/misc/sort-h-thousands-sep.sh: Cover the fix for this bug. Suggested by Pádraig Brady in http://bugs.gnu.org/24015 --- src/sort.c | 11 ++- tests/mi

bug#24015: [PATCH v2 1/3] sort: deduplicate code for traversing numbers

* src/sort.c (traverse_raw_number): New function for traversing numbers. (find_unit_order): Use traverse_raw_number () instead of open-coding it. (debug_key): Use traverse_raw_number () instead of open-coding it. --- src/sort.c | 63 ++ 1

bug#24015: [PATCH v2 2/3] sort: make -h work with -k and blank used as thousands separator

* src/sort.c (traverse_raw_number): Allow to skip only one occurrence of thousands_sep to avoid finding the unit in the next column in case thousands_sep matches as blank and is used as column delimiter. * tests/misc/sort-h-thousands-sep.sh: Add regression test for this bug. * tests/local.mk: Refer

bug#24015: [PATCH] sort: make -h work with -k and blank used as thousands separator

* src/sort.c (find_unit_order): Allow to skip only one occurrence of thousands_sep to avoid finding the unit in the next column in case thousands_sep matches as blank and is used as column delimiter. * tests/misc/sort-h-thousands-sep.sh: Add regression test for this bug. * tests/local.mk: Reference

bug#23868: [PATCH v2] install: with -Z, set default SELinux context also for directories

* doc/coreutils.texi (install invocation): Update -Z documentation. * src/install.c (make_ancestor): Set default security context before calling mkdir() if the -Z option is given. (process_dir): Call restorecon() on the destination directory if the -Z option is given. (usage): Update -Z documentati

bug#23868: [PATCH] install: with -Z, set default SELinux context also for directories

* doc/coreutils.texi (install invocation): Update -Z documentation. * src/install.c (make_ancestor): Set default security context before calling mkdir() if the -Z option was given. (process_dir): Call restorecon() on the destination directory if the -Z option was given. (usage): Update -Z documenta

bug#12020: ls should show when extended system attributes are set

On Sunday, July 22, 2012 18:16:39 Jim Meyering wrote: > Kamil Dudka wrote: > > On Sunday, July 22, 2012 14:40:46 Jim Meyering wrote: > >> When already using --color, we do get each test result for free > > > > Not really. The check for file capabilities is optional

bug#12020: ls should show when extended system attributes are set

On Sunday, July 22, 2012 14:40:46 Jim Meyering wrote: > When already using --color, we do get each test result for free Not really. The check for file capabilities is optional even with --color. The 'ca' indicator in $LS_COLORS needs to be set to a color to enable this. Kamil

bug#10282: change in behavior of du with multiple arguments (commit efe53cc)

On Tuesday 13 December 2011 18:16:12 Eric Blake wrote: > I think the proposal is to add a new option that forces du to reset its > duplicate inode hash table for each command line argument, to make > behavior more like traditional du, even though it means -s can then > output a larger usage by summ

bug#10282: change in behavior of du with multiple arguments (commit efe53cc)

On Tuesday 13 December 2011 08:09:08 Jim Meyering wrote: > Paul Eggert wrote: > > On 12/12/11 14:58, Eric Blake wrote: > >> "Files with multiple links shall be counted and written for only one > >> entry. The directory entry that is selected in the report is > >> unspecified." > > > > Yes, that's p

bug#10282: change in behavior of du with multiple arguments (commit efe53cc)

Hi, the following upstream commit introduces a major change in behavior of du when multiple arguments are specified: http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=efe53cc ... and the issue has landed as a bug in our Bugzilla: https://bugzilla.redhat.com/747075#c3 Was such a change

Re: ls command

On Wednesday 17 of March 2010 23:14:56 Andreas Schwab wrote: > That message comes from the shell (csh or tcsh). Indeed, confirmed off-list: On Thursday 18 of March 2010 16:53:27 Paul Gerber wrote: > The problem has been solved: > https://bugzilla.redhat.com/show_bug.cgi?id=529703 Kamil

Re: ls command

On Wed March 17 2010 18:17:38 Paul Gerber wrote: > What can one do if something that worked for years in various Unix > version stops working in a new release? > I assumed there would be continuity in such basic things. So far you didn't point us to any bug and/or change. Please specify what exa

Re: ls command

On Wed March 17 2010 15:32:06 Paul Gerber wrote: > RHEL5: The following two commands give different answers (Written by > Richard Stallman and David MacKenzie). Is that intended? > > Best regards, Paul Gerber > > > /bin/ls *.pdb > > > > 1fkn.pdb water_cluster.pdb > > > > /bin/ls *.pdb *.pdb.Z

Re: [PATCH] sort -V now ignores leading white spaces

Hi Pádraig, On Wed March 3 2010 14:45:50 Pádraig Brady wrote: > Also if your input is like this can one > just specify the -b flag globally or for the key? you're right. The option -b solves the problem fairly well. The patch is pointless. I've just taken the code from -n/-h because I hadn't

[PATCH] sort -V now ignores leading white spaces

5493d92bca31724b9d26d04f87dd3b9f13d1b123 Mon Sep 17 00:00:00 2001 From: Kamil Dudka Date: Wed, 3 Mar 2010 12:36:43 +0100 Subject: [PATCH] sort -V now ignores leading white spaces * src/sort.c (compare_version): Skip all white spaces before the call of filevercmp (). * tests/misc/sort-version: Add a related test case. * NEWS

Re: (no subject)

On Friday 29 of January 2010 18:11:53 Henry Hung wrote: > Hi > I don't know whether this is a design intent or a bug. > When I tried to list recursively a specified file, ls only searched the > current directory for the file, not recursively. For example, ls -R myFile* http://www.gnu.org/software/

Re: [PATCH v2] who --mesg now checks the group of TTY devices

On Saturday 23 of January 2010 02:43:39 Kamil Dudka wrote: > On Saturday 23 of January 2010 00:54:44 Kamil Dudka wrote: > > # ls -l /dev/tty? > > crw--w. 1 root root 4, 0 2010-01-22 18:48 /dev/tty0 > > crw--w. 1 root root 4, 1 2010-01-22 18:48 /dev/tty1 > > c

Re: [PATCH v2] who --mesg now checks the group of TTY devices

On Saturday 23 of January 2010 00:54:44 Kamil Dudka wrote: > # ls -l /dev/tty? > crw--w. 1 root root 4, 0 2010-01-22 18:48 /dev/tty0 > crw--w. 1 root root 4, 1 2010-01-22 18:48 /dev/tty1 > crw--w. 1 root tty 4, 2 2010-01-22 18:50 /dev/tty2 > crw---. 1 root root 4,

Re: [PATCH v2] who --mesg now checks the group of TTY devices

On Friday 22 of January 2010 17:03:51 Jim Meyering wrote: > Can you reproduce the situation in which this new configure-time > option is required on e.g., Fedora 12? So far, I haven't been able to, > since all tty devices properly get the "tty" group, and in that > case, the simple perm-comparison

[PATCH v2] who --mesg now checks the group of TTY devices

rly the lesser evil. It makes sense to me. Kamil From 55d223fee4900620d7147f134ebebe39fdca90a9 Mon Sep 17 00:00:00 2001 From: Kamil Dudka Date: Fri, 22 Jan 2010 15:17:19 +0100 Subject: [PATCH] who --mesg now checks the group of TTY devices ... if coreutils is compiled with --with-tty-group.

Re: How to overwrite the destination directory by 'cp'?

On Thursday 21 of January 2010 23:35:13 Peng Yu wrote: > Suppose I have directory a and b, the following command will copy the > content of a to b/a, rather than overwrite the directory 'b' by the > directory 'a'. I'm wondering if there is an option to overwrite 'b'? > > cp -r a b I don't think so

Re: [PATCH] who: --mesg now respects also group of a TTY

Hi Jim, thanks for review! On Thursday 21 of January 2010 12:28:03 Jim Meyering wrote: > Actually, more comments (in the code and log) would be welcome, too ;-) Sure. I also forgot the credit Piotr Gackiewicz as the original author in the first place... > Please add a little explanation before

[PATCH] who: --mesg now respects also group of a TTY

df522e97bd36b498cf75f4a7edd978f83388cdfd Mon Sep 17 00:00:00 2001 From: Kamil Dudka Date: Wed, 20 Jan 2010 16:15:37 +0100 Subject: [PATCH] who: --mesg now respects also group of a TTY ... when compiled with --with-tty-group * src/who.c (is_tty_writable): A new function returning true if a TTY

Re: [PATCH] ls.c: reorder includes to work around broken

On Saturday 09 of January 2010 22:40:08 Jim Meyering wrote: > I've added details (and "* src/ls.c: ...) to the log. Thanks for the amendment. Kamil

  1   2   3   >