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 a

Re: tests: dis/allow '.' in PATH?

On Tuesday, November 23, 2021 11:19:22 PM CET Bernhard Voelker wrote: > GNU findutils got a bug report for a failing test in the testsuite [1]. > It turned out that the calling environment had the current directory '.' > in PATH. This triggered a warning in `find -execdir ...` and therefore > made

Re: [PATCH] mountlist: recognize fuse.portal as dummy file system

On Tuesday, June 8, 2021 12:16:36 AM CEST Pádraig Brady wrote: > On 07/06/2021 13:43, Kamil Dudka wrote: > > This was originally proposed at: > > https://lists.gnu.org/archive/html/bug-gnulib/2021-02/msg00053.html > > > > As the full review might take some time, wo

[PATCH] mountlist: recognize fuse.portal as dummy file system

This was originally proposed at: https://lists.gnu.org/archive/html/bug-gnulib/2021-02/msg00053.html As the full review might take some time, would it be possible to apply at least the part related to fuse.portal file systems? They started to cause problems recently: https://bugs.launch

Re: tar + cpio - covscan issues

On Saturday, April 17, 2021 12:01:56 AM CEST Bruno Haible wrote: > Kamil Dudka wrote: > > > Downstream consumers can exclude the gnulib-copied directories using the > > > 'csgrep' program, AFAIU? > > > > Not so easily. csgrep can filter the results

Re: tar + cpio - covscan issues

On Thursday, April 15, 2021 10:30:14 PM CEST Paul Eggert wrote: > On 4/15/21 1:07 PM, Kamil Dudka wrote: > > People maintaining their own medium-size projects can easily play with > > this. I am in a different situation when I need to scan 3700 distinct > > projects and appr

Re: tar + cpio - covscan issues

Hi Bruno, On Saturday, April 10, 2021 8:40:06 PM CEST Bruno Haible wrote: > Hi Kamil, > > > I meant the public reports on this mailing-list like the one that Ondrej > > sent. As gnulib is embedded in multiple RPM packages of Fedora/RHEL, such > > reports are going to come periodically until you c

Re: tar + cpio - covscan issues

On Saturday, April 10, 2021 3:58:57 PM CEST Bruno Haible wrote: > Kamil Dudka wrote: > Paul and I receive a mail with the *new* issues once a week. We never review > the same issue more than once. I was not talking about the private notifications you get from Coverity Scan. I meant t

Re: tar + cpio - covscan issues

On Saturday, April 10, 2021 12:26:37 PM CEST Bruno Haible wrote: > Hi Ondrej, > > > proposing patch for some of the issues found by coverity scan in tar-1.34 > > Thanks for these reports. > > When we get Coverity reports, we fix the things that are valid complaints > about the code, but we do NO

Re: [PATCH] utimens: fix confusing arg type in internal func

On Saturday, April 10, 2021 3:19:08 AM CEST Paul Eggert wrote: > On 4/9/21 12:50 AM, Kamil Dudka wrote: > > The warning[-Wstringop-overflow=] reports you refer to come from GCC > > actually. > Weird. The code being warned about has nothing to do with strings, and > the only st

Re: [PATCH] utimens: fix confusing arg type in internal func

On Thursday, April 8, 2021 2:30:42 AM CEST Paul Eggert wrote: > Although the old code was technically correct, this was accidental > and it understandably confused Coverity. Reported by Ondrej Dubaj in: > https://lists.gnu.org/r/bug-tar/2021-04/msg0.html The warning[-Wstringop-overflow=] repo

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 f

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 either

Re: [PATCH] mountlist: recognize more file system types as remote

On Tuesday, October 27, 2020 10:23:15 PM CET Pádraig Brady wrote: > Sync "remote" file systems from stat.c in coreutils. > Note we only consider file systems that do not use host:resource > mount source. I.e. those that don't generally use a colon when > mounting, as that case is already considere

Re: Test suite failure for gettext's gnulib on ARMv7HL

On Friday, August 7, 2020 9:18:31 PM CEST Bruno Haible wrote: > [Dropping bug-gettext from CC] > > Kamil Dudka wrote: > > > One of these lines must modify its contents. The question is: where? > > > > > > msg4 = strerror (1729576); > > > >

Re: Test suite failure for gettext's gnulib on ARMv7HL

On Tuesday, August 4, 2020 2:10:46 AM CEST Bruno Haible wrote: > Kamil Dudka wrote: > > Yes, the `ASSERT (msg3 == msg4 || STREQ (msg3, str3))` check is failing here: > > https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=tests/test-> > > > strerro

Re: Test suite failure for gettext's gnulib on ARMv7HL

On Monday, August 3, 2020 2:57:22 PM CEST Bastien Nocera wrote: > On Mon, 2020-08-03 at 12:55 +0200, Kamil Dudka wrote: > > On Friday, July 31, 2020 6:47:08 PM CEST Bastien Nocera wrote: > > > Hey, > > > > > > Gettext 0.20.2's gnulib copy has its test

Re: Test suite failure for gettext's gnulib on ARMv7HL

On Friday, July 31, 2020 6:47:08 PM CEST Bastien Nocera wrote: > Hey, > > Gettext 0.20.2's gnulib copy has its test suite failing on Fedora > rawhide on ARMv7HL. I'm afraid that it's Friday late in the day, and I > don't have much more information than what's available in the build > logs. > > Th

Re: [PATCH] nstrftime: better width support for %N, %z

On Thursday, May 21, 2020 2:35:12 AM CEST Paul Eggert wrote: > On 5/20/20 10:51 AM, Kamil Dudka wrote: > > If the change is intended, the documentation of `date` should be updated > > Thanks for mentioning this. The change was intended, and I installed the > attached patch

Re: [PATCH] nstrftime: better width support for %N, %z

On Friday, December 6, 2019 11:51:31 PM CEST Paul Eggert wrote: > * lib/nstrftime.c (width_add, width_add1, width_cpy): > New macros, which generalize ‘add’, ‘add1’, ‘cpy’ by adding > a new WIDTH parameter. > (add, add1, cpy): Use these macros. > (width_add): Do not treat digits == 0 as a special c

Re: reclaiming memory before exit

On Friday, May 15, 2020 5:16:28 AM CEST Paul Eggert wrote: > On 5/14/20 5:11 PM, Jeffrey Walton wrote: > > Not everyone has GNU's low standards. > > Now may be a good time to remind us of the GNU Kind Communications > Guideline; see . > Let's

Re: gcc -fanalyze

On Friday, May 15, 2020 5:11:40 AM CEST Paul Eggert wrote: > On 5/14/20 1:34 AM, Kamil Dudka wrote: > > Now I see that we can just > > build coreutils with -Dlint even for binary RPMs without any drawbacks. > > Good, and that also means you don't need the coreutils-8.3

Re: gcc -fanalyze

On Thursday, May 14, 2020 6:23:19 AM CEST Paul Eggert wrote: > I doubt whether anybody will care about that "waste"; it's just a few > instructions. Good point. I did not look at what merge_tree_destroy() and queue_destroy() really do and thought that their complexity was O(n). Now I see that w

Re: gcc -fanalyze

On Tuesday, May 12, 2020 11:58:49 PM CEST Paul Eggert wrote: > On 5/12/20 10:49 AM, Kamil Dudka wrote: > > The problem is that such > > false positives may easily turn out into true positives, as the code gets > > changed, and nobody will notice it. > > Sounds extremel

Re: gcc -fanalyze

On Tuesday, May 12, 2020 6:23:33 PM CEST Paul Eggert wrote: > 3. If you don't like false alarms from GCC or from other static analyzers, > filter them out (or get better analyzers...). You can filter in many > different ways (e.g., by comparing the warnings you got last time from the > ones you got

Re: gcc -fanalyze

On Monday, May 11, 2020 7:26:34 PM CEST Paul Eggert wrote: > On 5/11/20 12:43 AM, Kamil Dudka wrote: > > It is usually bad idea to use different versions of source code for > > compilers and for static analyzers. > > Yes, I don't like it either. The patch I installed was

Re: gcc -fanalyze

On Monday, May 11, 2020 9:17:39 PM CEST Bruno Haible wrote: > I agree with Paul, for three reasons: > > * We, the developers, should decide how our programs look like. It's not > only a question of pride - even if that pride is only about having save a > 'xorl %eax,%eax' instruction. It's a qu

Re: gcc -fanalyze

On Sunday, May 10, 2020 3:13:41 AM CEST Paul Eggert wrote: > The first bug in that output: > > cc1: warning: function may return address of local variable > [-Wreturn-local-addr] lib/careadlinkat.c:73:8: note: declared here >73 | char stack_buf[1024]; > > |^ > > This

Re: find command trigger coredump

On Thursday, April 16, 2020 6:03:45 AM CEST Paul Eggert wrote: > Thanks for the bug report archived at > . What you appear > to be saying is that the Gnulib fts NOSTAT_LEAF_OPTIMIZATION code is buggy > when an XFS filesystem is mutating, and

Re: [PATCH] fchmodat, lchmod: port to buggy Linux filesystems

On Tuesday, March 10, 2020 8:30:36 PM CET Florian Weimer wrote: > * Pádraig Brady: > > On 10/03/2020 11:52, Florian Weimer wrote: > >> * Pádraig Brady: > >>> On 09/03/2020 18:51, Paul Eggert wrote: > On 3/9/20 10:30 AM, Pádraig Brady wrote: > > A very similar "ENOTSUP" problem is being rep

Re: [PATCH] fchmodat, lchmod: port to buggy Linux filesystems

On Tuesday, March 10, 2020 12:52:14 PM CET Florian Weimer wrote: > * Pádraig Brady: > > I've requested an strace from the failing system. The strace in the failing case looks like this: [...] umask(000) = 022 umask(022) = 000 mknod("/dev/r

parse-datetime: invalid date range shifted by 30 minutes for Singapore TZ

In 1981, there was a change in TZ for Singapore and Malaysia which went from UTC+7.5 to UTC+8. It happened at 1981-12-31 23:30:00 which became 1982-01-01 00:00:00. As I understand it, the range 1981-12-31 23:30:00 .. 1981-12-31 23:59:59 should be invalid, whereas the range 1982-01-01 00:00:00

Re: Coverity false positives triggered by gnulib's implementation of base64

On Friday, May 10, 2019 4:11:45 PM CEST Bruno Haible wrote: > Kamil Dudka wrote: > > Thanks! This also helps to suppress the false positives on cryptsetup > > with Coverity Static Analysis version 2019.03. > > Good! Since this is the approach that Paul prefers, I'm push

Re: Coverity false positives triggered by gnulib's implementation of base64

On Friday, May 10, 2019 12:13:32 AM CEST Bruno Haible wrote: > Hi Paul, > > > Sorry, I'm still not following. Unless the tainted data is used to > > calculate an array index, there's no problem with Heartbleed and the > > Coverity heuristic should not diagnose a problem. > > Yes, IF they were onl

Re: Coverity false positives triggered by gnulib's implementation of base64

On Friday, May 10, 2019 1:34:55 PM CEST Florian Weimer wrote: > * Kamil Dudka: > >> For example, how do you know that the reports are false positives and not > >> true positives? > > > > I think it was obvious from my previous explanation: > > > >

Re: Coverity false positives triggered by gnulib's implementation of base64

atedly review these false positives > > and waive them in each single instance of these tools. And even worse > > with > > gnulib because these false positives are usually not matched across > > different project that bundle gnulib, even if you have a single instance >

Re: Coverity false positives triggered by gnulib's implementation of base64

On Thursday, May 9, 2019 9:14:40 PM CEST Paul Eggert wrote: > On 5/7/19 7:22 AM, Kamil Dudka wrote: > > It triggered the following false positives in the cryptsetup project: > > > > Error: TAINTED_SCALAR: > > lib/luks2/luks2_digest_pbkdf2.c:117: tainted_data_arg

Re: Why does close_stdout close stdout and stderr?

On Friday, May 10, 2019 12:17:11 AM CEST Paul Eggert wrote: > On 5/8/19 11:39 PM, Florian Weimer wrote: > > atexit handlers run before ELF destructors (and some C++ destructors). > > There can also be multiple such handlers. So it's not true that an > > atexit handler always runs last. > > OK, bu

Re: Coverity false positives triggered by gnulib's implementation of base64

Hi Bruno, On Wednesday, May 8, 2019 10:15:37 AM CEST Bruno Haible wrote: > Hi Kamil, > > > Coverity Analysis 2019.03 incorrectly marks the input argument > > of base64_encode(), and conseuqnetly base64_encode_alloc(), as > > tainted_data_sink because it sees byte-level operations on the input. >

Coverity false positives triggered by gnulib's implementation of base64

Coverity Analysis 2019.03 incorrectly marks the input argument of base64_encode(), and conseuqnetly base64_encode_alloc(), as tainted_data_sink because it sees byte-level operations on the input. It triggered the following false positives in the cryptsetup project: Error: TAINTED_SCALAR: lib/luk

Re: make signal handlers more reliable

On Tuesday, March 19, 2019 3:46:54 AM CET Paul Eggert wrote: > Is there some reasonable way to cajole GCC into doing this checking? There is a work-in-progress GCC plug-in that checks signal handlers for uses of functions that are not async-signal-safe: https://github.com/dkozovsk/handler_plug ht

Re: cmake support

BUILD_COMMAND echo > INSTALL_COMMAND echo > ) > add_dependencies(fewer gnulib) > target_include_directories(fewer PUBLIC > gnulib-prefix/src/gnulib-build/lib) > target_link_libraries(fewer libgnu) > endif() > > On Sun, Jan 6, 2019 at 3:37 AM Kamil Dudka

Re: cmake support

) path and this is most likely not going to change because gnulib's developers do not want gnulib to be used this way: https://www.gnu.org/software/gnulib/manual/html_node/Library-vs-Reusable-Code.html#Library-vs-Reusable-Code Kamil > On Sat, Jan 5, 2019 at 12:31 PM Kamil Dudka wrote: &

Re: cmake support

On Saturday, January 5, 2019 6:53:06 PM CET Bruno Haible wrote: > Hi, > > Andrew Pennebaker wrote: > > Could we improve how gnulib integrates with downstream projects, to make > > it > > easier to work with different build tools? In particular, would be helpful > > for gnulib to easily work with c

Re: [PROPOSED] renameatu: rename from renameat2

On Wednesday, July 4, 2018 4:45:32 AM CEST Paul Eggert wrote: > It's looking like Glibc will add a renameat2 function > that is incompatible with Gnulib renameat2; see: > https://sourceware.org/ml/libc-alpha/2018-07/msg00064.html > To help avoid future confusion, rename renameat2 to something else.

Re: 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); > +

Re: [PATCH 5/6] fts: three levels of leaf optimization

On Monday, April 16, 2018 5:54:42 PM CEST Kamil Dudka wrote: > On Wednesday, April 11, 2018 9:53:25 PM CEST Paul Eggert wrote: > > On 04/11/2018 07:03 AM, Kamil Dudka wrote: > > > As far as I know, there is currently no fix available for that. > > > > I looked in

Re: [PATCH 5/6] fts: three levels of leaf optimization

On Wednesday, April 11, 2018 9:53:25 PM CEST Paul Eggert wrote: > On 04/11/2018 07:03 AM, Kamil Dudka wrote: > > As far as I know, there is currently no fix available for that. > > I looked into this and found some bugs in relevant code (bugs that I > introduced last summer; so

Re: [PATCH 5/6] fts: three levels of leaf optimization

On Wednesday, April 11, 2018 3:38:40 PM CEST James Youngman wrote: > On Thu, Apr 5, 2018 at 4:49 PM, Paul Eggert wrote: > > On 04/05/2018 05:44 AM, Kamil Dudka wrote: > >> Does this change (intentionally?) enable leaf optimization for CIFS? > > > > No, I wasn'

Re: [PATCH 5/6] fts: three levels of leaf optimization

On Tuesday, April 10, 2018 9:54:26 PM CEST Bernhard Voelker wrote: > Hi Kamil, > > On 04/06/2018 09:29 AM, Kamil Dudka wrote: > > On Friday, April 6, 2018 8:08:55 AM CEST Bernhard Voelker wrote: > >> On 04/05/2018 02:44 PM, Kamil Dudka wrote: > >>> The same &

Re: [PATCH 5/6] fts: three levels of leaf optimization

On Friday, April 6, 2018 9:27:07 AM CEST Kamil Dudka wrote: > On Thursday, April 5, 2018 5:49:15 PM CEST Paul Eggert wrote: > > On 04/05/2018 05:44 AM, Kamil Dudka wrote: > > > Does this change (intentionally?) enable leaf optimization for CIFS? > > > > No, I was

Re: [PATCH 5/6] fts: three levels of leaf optimization

On Friday, April 6, 2018 8:08:55 AM CEST Bernhard Voelker wrote: > CCing bug-findutils. > original post https://lists.gnu.org/r/bug-gnulib/2018-04/msg00015.html > > On 04/05/2018 02:44 PM, Kamil Dudka wrote: > > We have a bug report where find aborts while traversing

Re: [PATCH 5/6] fts: three levels of leaf optimization

On Thursday, April 5, 2018 5:49:15 PM CEST Paul Eggert wrote: > On 04/05/2018 05:44 AM, Kamil Dudka wrote: > > Does this change (intentionally?) enable leaf optimization for CIFS? > > No, I wasn't thinking about CIFS when I wrote that. Thanks for reporting > it. I installed

Re: [PATCH 5/6] fts: three levels of leaf optimization

On Tuesday, July 25, 2017 9:28:05 AM CEST Paul Eggert wrote: > * lib/fts.c (enum leaf_optimization): New type with three values. > (S_MAGIC_AFS): New macro. Sort them. > (leaf_optimization): Rename from leaf_optimization_applies, and > return enum leaf_optimization instead of bool. All uses chang

Re: [PATCH 1/2] fts: do not use the getcwdat module

On Thursday, March 22, 2018 12:12:59 AM CET Jim Meyering wrote: > On Wed, Mar 21, 2018 at 7:44 AM, Kamil Dudka wrote: > > ... because there is no such module in gnulib > > --- > > > > lib/fts.c | 26 +- > > 1 file changed, 5 insertions(

[PATCH 2/2] fts: make the code compile with -DFTS_DEBUG

--- lib/fts.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/lib/fts.c b/lib/fts.c index 4195f6170..7983320b7 100644 --- a/lib/fts.c +++ b/lib/fts.c @@ -253,8 +253,11 @@ static int fts_safe_changedir (FTS *, FTSENT *, int, const char *) # include # include

[PATCH 1/2] fts: do not use the getcwdat module

... because there is no such module in gnulib --- lib/fts.c | 26 +- 1 file changed, 5 insertions(+), 21 deletions(-) diff --git a/lib/fts.c b/lib/fts.c index bfa73e31e..4195f6170 100644 --- a/lib/fts.c +++ b/lib/fts.c @@ -253,7 +253,6 @@ static int fts_safe_changedir

Re: discussion references

On Monday, March 19, 2018 8:59:53 PM CET Bruno Haible wrote: > Kamil Dudka wrote: > > > For gnulib, you sometimes need to look up in the mailing list archive to > > > get the complete discussion. > > > > Ideally yes. But the commit contains no reference to that

Re: parse-datetime.c generated in the source (instead of build) directory

On Saturday, March 17, 2018 1:37:24 AM CET Bruno Haible wrote: > Kamil Dudka wrote: > > parse-datetime.c generated out of parse-datetime.y ends up in the source > > directory, instead of the build directory as one would expect. This was > > introduced by the following

parse-datetime.c generated in the source (instead of build) directory

parse-datetime.c generated out of parse-datetime.y ends up in the source directory, instead of the build directory as one would expect. This was introduced by the following commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=6c680191 Neither the comment, nor the change log

Re: [PATCH 1/2] fts: introduce the FTS_NOLEAF flag

On Friday, September 8, 2017 8:51:11 AM CEST Paul Eggert wrote: > > On 09/12/15 10:35, Pádraig Brady wrote: > >> p.s. I see that find does a stat per file on XFS, > >> while d_type can be used to distinguish dirs there. > >> On XFS DT_DIR is set for dirs and DT_UNKNOWN otherwise. > >> I wonder is t

Re: [PATCH 1/2] fts: introduce the FTS_NOLEAF flag

On Thursday, December 10, 2015 2:26:38 AM CEST Pádraig Brady wrote: > On 09/12/15 10:35, Pádraig Brady wrote: > > On 09/12/15 06:34, Kamil Dudka wrote: > >> The flag is needed to implement the -noleaf option of find. > >> * lib/fts.c (link_count_optimize_ok): Im

Re: [PATCH] dfa: port to gcc -fsanitize=undefined

On Monday, January 16, 2017 11:57:03 Paul Eggert wrote: > Kamil Dudka wrote: > > It can cause a real crash in certain execution environments. > > Which ones? I'm not interested in environments like -fsanitize=undefined, > which is designed to catch violations of the standa

Re: [PATCH] dfa: port to gcc -fsanitize=undefined

On Monday, January 16, 2017 10:29:34 Eric Blake wrote: > On 01/15/2017 08:09 PM, Paul Eggert wrote: > > * lib/dfa.c (copy): Don’t pass NULL with size 0 to memcpy, > > as this runs afoul of gcc -fsanitize=undefined. > > It's lame that gcc warns on that usage; I'm half-tempted to propose a > POSIX b

Re: read-write locks

On Thursday, January 05, 2017 21:13:07 Bruno Haible wrote: > Torvald Riegel wrote: > > IMO, users of reader-writer locks should treat them as a > > mutual-exclusion mechanism. That is, a mechanism that just ensures that > > two critical sections will not execute concurrently (except if both are >

[PATCH] mountlist: recognize autofs-mounted remote file systems, too

ions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index d2cb956..ba1fc39 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2016-02-19 Kamil Dudka + mountlist: recognize autofs-mounted remote file systems, too + Originally reported at: https://bugzilla.redhat.c

Re: [PATCH 1/2] fts: introduce the FTS_NOLEAF flag

On Monday 18 January 2016 17:33:54 Pádraig Brady wrote: > On 18/01/16 16:25, Pádraig Brady wrote: > > On 18/01/16 16:10, Kamil Dudka wrote: > >> On Monday 21 December 2015 15:01:56 Kamil Dudka wrote: > >>> On Monday 21 December 2015 00:05:51 Pádraig Brady wrote: >

Re: [PATCH 1/2] fts: introduce the FTS_NOLEAF flag

On Monday 21 December 2015 15:01:56 Kamil Dudka wrote: > On Monday 21 December 2015 00:05:51 Pádraig Brady wrote: > > On the other hand we've had no reports of issues with the > > existing auto config done by FTS. > > Because the leaf optimization has been enabled for re

test-isinf compiled by gcc-5.3.1 fails on ppc64le

Fedora ppc64le toolchain recently changed expansion of the isinf() macro, which causes the !isinf(LDBL_MAX) assertion to fail when using the LDBL_MAX value defined by gnulib. On the other hand, it still works correctly when using the LDBL_MAX value defined by the toolchain. The -D__SUPPORT_SNA

Re: [PATCH 1/2] fts: introduce the FTS_NOLEAF flag

On Monday 21 December 2015 00:05:51 Pádraig Brady wrote: > On the other hand we've had no reports of issues with the > existing auto config done by FTS. Because the leaf optimization has been enabled for reiserfs only until now. I suspect that NFS will not be that easy and such file system issues

Re: [PATCH 1/2] fts: introduce the FTS_NOLEAF flag

On Thursday 10 December 2015 01:26:38 Pádraig Brady wrote: > I also noticed a lot of fcntl calls on XFS > (basically one per file), which I need to look further into: > $ strace -c find/find /usr/share >/dev/null > % time seconds usecs/call callserrors syscall > -- --

Re: [PATCH 1/2] fts: introduce the FTS_NOLEAF flag

On Wednesday 09 December 2015 10:35:25 Pádraig Brady wrote: > On 09/12/15 06:34, Kamil Dudka wrote: > > The flag is needed to implement the -noleaf option of find. > > * lib/fts.c (link_count_optimize_ok): Implement the FTS_NOLEAF flag. > > * lib/fts_.h (FTS_NOLEAF): New macro

[PATCH 2/2] fts: enable leaf optimization for NFS

NFS provides usable dirent.d_type but not necessarily for all entries of large directories. See for details. * lib/fts.c (leaf_optimization_applies): Append NFS on the white list. --- lib/fts.c | 5 + 1 file changed, 5 insertions(+) diff --git a/lib/fts.

[PATCH 1/2] fts: introduce the FTS_NOLEAF flag

The flag is needed to implement the -noleaf option of find. * lib/fts.c (link_count_optimize_ok): Implement the FTS_NOLEAF flag. * lib/fts_.h (FTS_NOLEAF): New macro, shifted conflicting constants. --- lib/fts.c | 4 lib/fts_.h | 12 +--- 2 files changed, 13 insertions(+), 3 deletio

[PATCH v2] fts: avoid crash when a cycle is added while traversing

+ lib/fts.c | 13 ++--- 2 files changed, 19 insertions(+), 3 deletions(-) diff --git a/ChangeLog b/ChangeLog index c4cb47f..9daa33c 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2015-02-11 Kamil Dudka + + fts: avoid crash when a cycle is added while traversing

[PATCH] fts: fix a crash triggered by recursive bind mount

insertions(+), 3 deletions(-) diff --git a/ChangeLog b/ChangeLog index c4cb47f..33387c5 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2015-02-11 Kamil Dudka + + fts: fix a crash triggered by recursive bind mount + Reported by Michael Chapman in: https://bugzilla.redhat.com

Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L

On Wednesday 05 October 2011 17:31:07 Jim Meyering wrote: > Bruno Haible wrote: > > Jim Meyering wrote: > >> I propose to push Kamil's fix (mainly to have a record of it, > >> in case we need it later), but then to immediately revert it > >> along with the file-has-acl.c change that started this. >

Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L

On Monday 03 October 2011 22:47:38 Bastien ROUCARIES wrote: > On Mon, Oct 3, 2011 at 8:53 PM, Kamil Dudka wrote: > > On Monday 03 October 2011 20:46:59 Bastien ROUCARIES wrote: > >> Yes it is possible to mount file and it is call a bind mount. See man > >> page of mount

Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L

On Monday 03 October 2011 20:46:59 Bastien ROUCARIES wrote: > Yes it is possible to mount file and it is call a bind mount. See man page > of mount, and it is used in pratice essentially for /dev/null but it could > be used for any regular file Thanks for the hint. I did not know this. Luckily,

Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L

On Monday 03 October 2011 20:13:53 Bruno Haible wrote: > Kamil Dudka wrote: > > > a) A non-symlink, non-directory. Here acl_extended_file_nofollow and > > > acl_extended_file are equivalent. > > > > If I understand this, you expect non-directories cannot b

Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L

On Monday 03 October 2011 19:54:12 Kamil Dudka wrote: > On Monday 03 October 2011 18:25:10 Bruno Haible wrote: > > g) Must return 0. > > h) Must return 0. > > i) Must return 0. > > Does the above mean that you want to change the current behavior of ls -l? Please

Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L

On Monday 03 October 2011 18:25:10 Bruno Haible wrote: > g) Must return 0. > h) Must return 0. > i) Must return 0. Does the above mean that you want to change the current behavior of ls -l? Kamil

Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L

On Monday 03 October 2011 18:25:10 Bruno Haible wrote: > Kamil Dudka wrote: > > > 2) see a test case added to gnulib or coreutils. > > > > A while ago, Jim wrote a test-case for coreutils that catches exactly the > > bug that the original patch introduced. > >

Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L

p 17 00:00:00 2001 > From: Kamil Dudka > Date: Mon, 3 Oct 2011 12:17:22 +0200 > Subject: [PATCH] file-has-acl: revert unintended change in behavior of ls > -L > > * lib/file-has-acl.c (acl_extended_file_wrap): New function, > derived from... > (file_has_acl): ...code here. Call

Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L

On Mon October 3 2011 15:45:36 Bruno Haible wrote: > In fact, the code already does this, at the beginning of the function > file_has_acl. So in case c) the big compound statement is skipped, and the > function immediately does a "return 0". The patch that you proposed on > 2011-04-06 and committed

Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L

On Mon October 3 2011 15:45:36 Bruno Haible wrote: > Kamil Dudka wrote: > > The commit 95f7c57 introduced an unintended change in behavior of ls -L. > > I am attaching a patch that restores the old behavior. > > This patch introduces an additional lstat() system call Yes

Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L

links. */ Comment replaced. Thanks for the suggestion. Kamil From 25b63ddf75d2ca5c86e8498f54ee9001b72c4c2c Mon Sep 17 00:00:00 2001 From: Kamil Dudka Date: Mon, 3 Oct 2011 12:17:22 +0200 Subject: [PATCH] file-has-acl: revert unintended change in behavior of ls -L * lib/file-has-acl.c (acl_ex

Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L

On Mon October 3 2011 15:00:46 Jim Meyering wrote: > Here's a version of your patch that I find more readable: > - prefer if (CONDITION) over #if CONDITION, when possible > - document the code more in comments, less in the commit log > Is this ok with you? Sure. Thanks for the improvements!

Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L

On Mon October 3 2011 13:51:39 Jim Meyering wrote: > From: Jim Meyering > Date: Mon, 3 Oct 2011 13:49:47 +0200 > Subject: [PATCH] tests: add a test to exercise today's ls-lL-vs-ACL bug > > * tests/ls/slink-acl: New file. > * tests/Makefile.am (TESTS): Add it. > * tests/init.cfg (require_setfacl_)

Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L

On Mon October 3 2011 13:09:21 Jim Meyering wrote: > Kamil Dudka wrote: > > On Mon October 3 2011 12:45:01 Jim Meyering wrote: > >> Can you describe how to make "ls -L" misbehave without this patch? > > > > if you have a symlink to a file with ACL, '

Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L

Hi Jim, On Mon October 3 2011 12:45:01 Jim Meyering wrote: > Can you describe how to make "ls -L" misbehave without this patch? if you have a symlink to a file with ACL, 'ls -Ll' does not print the '+' at end of the column with permission bits. > I.e., if there isn't already a test in coreutils

[PATCH] file-has-acl: revert unintended change in behavior of ls -L

The commit 95f7c57 introduced an unintended change in behavior of ls -L. I am attaching a patch that restores the old behavior. Thanks in advance for considering the patch! Kamil From 75836c03cb21d616591b11164b626556d9f26152 Mon Sep 17 00:00:00 2001 From: Kamil Dudka Date: Mon, 3 Oct 2011 12:17

Re: [PATCH] file-has-acl: use acl_extended_file_nofollow() if available

On Fri July 22 2011 15:25:13 Jim Meyering wrote: > Kamil Dudka wrote: > > On Wednesday 06 April 2011 16:49:31 Kamil Dudka wrote: > >> the attached patch allows ls(1) from coreutils to eliminate unnecessary > >> calls of getxattr() and thus prevents it from triggerring un

Re: [PATCH] file-has-acl: use acl_extended_file_nofollow() if available

On Wednesday 06 April 2011 16:49:31 Kamil Dudka wrote: > Hello, > > the attached patch allows ls(1) from coreutils to eliminate unnecessary > calls of getxattr() and thus prevents it from triggerring unnecessary > mounts while listing files. The feature is enabled automat

[PATCH] file-has-acl: use acl_extended_file_nofollow() if available

following bug for more details: https://bugzilla.redhat.com/692823 Thanks in advance for considering the patch! Kamil From 11097f2d5f8dd86cef9f0dbd71c2655377561f5e Mon Sep 17 00:00:00 2001 From: Kamil Dudka Date: Wed, 6 Apr 2011 16:39:44 +0200 Subject: [PATCH] file-has-acl: use

Re: [PATCH] fts: do not fail on a submount during traversal

Hi Jim, On Thu November 12 2009 12:44:48 Jim Meyering wrote: > I've applied and pushed that. thanks for considering it! > I adjusted the comment, since I view this addition not as a feature, > but rather as a kludge to work around brokenness in the NFS4 > implementation. Even though it affects

[PATCH] fts: do not fail on a submount during traversal

completely. So please don't shout at me I screwed it up :-) Kamil From 239d400abe783ad297b547e4e5a281cc1613ef70 Mon Sep 17 00:00:00 2001 From: Kamil Dudka Date: Tue, 10 Nov 2009 14:26:56 +0100 Subject: [PATCH] fts: do not fail on a submount during traversal * lib/fts.c (fts_build): Read the s

Re: FTS not ready for a remount during traversal

Hi Jim, On Wed November 4 2009 13:02:33 Jim Meyering wrote: > I've built with it and compared before/after performance > using an all-directories hierarchy on a tmpfs file system. > > The result is a >10% performance decrease in this contrived worst case: thanks for stating the upper boundary es

Re: FTS not ready for a remount during traversal

m/501848 Let me know if there is anything missing. A new version of the patch is attached. Any feedback welcome! Kamil From 69fd52bd5c7c4f71629a9a756548bc02ef8905db Mon Sep 17 00:00:00 2001 From: Kamil Dudka Date: Tue, 3 Nov 2009 14:14:53 +0100 Subject: [PATCH] fts: do not fail on a submount during tr

  1   2   >