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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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:

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

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

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 even with --color. The 'ca

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

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 summing

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 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 *.pdb.gz

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

[PATCH] sort -V now ignores leading white spaces

5493d92bca31724b9d26d04f87dd3b9f13d1b123 Mon Sep 17 00:00:00 2001 From: Kamil Dudka kdu...@redhat.com 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

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

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*

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

: Kamil Dudka kdu...@redhat.com 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. Based on a patch written by Piotr Gackiewicz. Details at https://bugzilla.redhat.com/454261 * src/who.c

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 test

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, 3 2010-01-22 18:48

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

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

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

df522e97bd36b498cf75f4a7edd978f83388cdfd Mon Sep 17 00:00:00 2001 From: Kamil Dudka kdu...@redhat.com 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

Re: ls.c doesn't compile

On Friday 08 of January 2010 11:08:48 Jean Philippe EIMER wrote: Compiling coreutils 8.3 fails at ls.c, with gcc 4.4.2, glibc 2.11.1 and kernel 2.6.32.3 : In file included from /usr/include/bits/sigcontext.h:28, from /usr/include/signal.h:339, from

[PATCH] ls.c: reorder includes to work around broken sys/capability.h

On Saturday 09 of January 2010 21:00:56 Kamil Dudka wrote: It looks to me like https://bugzilla.redhat.com/483548 - it has been discussed several times on this mailing list. You can find it going through the archive. As the problem still persists on some systems, it drives me to another idea

Re: [PATCH] ls.c: reorder includes to work around broken sys/capability.h

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   >