Re: coreutils-9.3 released [stable]

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

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

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:

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 by path in

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

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

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

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

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

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

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

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

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

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

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

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

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 s

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

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

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

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

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

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

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 part

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

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,

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

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

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

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

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

iew 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 > > of th

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,

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:

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

Re: cmake support

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 wrote: > > On Sun

Re: cmake support

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: > > On Saturday

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

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

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

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 <egg...@cs.ucla.edu> wrote: > > On 04/05/2018 05:44 AM, Kamil Dudka wrote: > >> Does this change (intentionally?) enable leaf optimization for CIFS? > > &

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 t

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

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 <kdu...@redhat.com> wrote: > > ... because there is no such module in gnulib > > --- > > > > lib/fts.c | 26 +- > > 1 file

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

[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

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

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

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 <kdu...@redhat.com> + mountlist: recognize autofs-mounted remote file systems, too + Originally reported at: https://bug

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 reiserf

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

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

[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

[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 kdu...@redhat.com + + fts: avoid crash when a cycle is added

[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 kdu...@redhat.com + + fts: fix a crash triggered by recursive bind mount + Reported by Michael Chapman in: https

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

[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 kdu...@redhat.com Date: Mon

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 to

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, 'ls -Ll' does not print the '+' at end of the column

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 meyer...@redhat.com 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

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

a/ChangeLog b/ChangeLog index a6d363a..81d9b93 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2011-10-03 Kamil Dudka kdu...@redhat.com + + file-has-acl: revert unintended change in behavior of ls -L + * lib/file-has-acl.c (acl_extended_file_wrap): A wrapper around + acl_extended_file

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. , when it is not necessary

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 on

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

On Monday 03 October 2011 16:42:20 Jim Meyering wrote: Kamil, I've merged your two comment changes, kept my commit-log and ChangeLog and rebased past Bruno's latest change. This is what I expect to push: From 603b1e3b16894cac183952b0b0fe379749a3aebe Mon Sep 17 00:00:00 2001 From: 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. I'm asking for a test case also for the bug

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 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 ignore this. The above is correct

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 22:47:38 Bastien ROUCARIES wrote: On Mon, Oct 3, 2011 at 8:53 PM, Kamil Dudka kdu...@redhat.com 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, and it is used

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 unnecessary mounts while listing

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

the 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 kdu...@redhat.com Date: Wed, 6 Apr 2011 16:39:44 +0200 Subject: [PATCH] file-has-acl: use

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

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

please don't shout at me I screwed it up :-) Kamil From 239d400abe783ad297b547e4e5a281cc1613ef70 Mon Sep 17 00:00:00 2001 From: Kamil Dudka kdu...@redhat.com 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 stat

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

Re: FTS not ready for a remount during traversal

version of the patch is attached. Any feedback welcome! Kamil From 69fd52bd5c7c4f71629a9a756548bc02ef8905db Mon Sep 17 00:00:00 2001 From: Kamil Dudka kdu...@redhat.com Date: Tue, 3 Nov 2009 14:14:53 +0100 Subject: [PATCH] fts: do not fail on a submount during traversal * lib/fts.c (fts_build

FTS not ready for a remount during traversal

Hello, the FTS module does not seem to be ready for a remount during traversal. As a minimal example we can take the following situation: https://bugzilla.redhat.com/show_bug.cgi?id=501848#c20 Descending a directory triggers a shrinkable mount which implies a change of the device number.

  1   2   >