Re: Issue with ls -v / sort -V and strverscmp() usage

On Monday 22 September 2008 14:36:02 Eric Blake wrote: > On the other hand, the fact that strverscmp provides a distinction based > on leading zeros is nice, as it guarantees a stable sort (no two strings > that differ on strcmp will compare equal with strverscmp). Good point, thanks. The function

[PATCH] add new module filevercmp

gcc parameters to catch all unportable code in this module? Thanks in advance. Kamil From 842bccfc33b46570b73956e39be8c0d9c064453b Mon Sep 17 00:00:00 2001 From: Kamil Dudka <[EMAIL PROTECTED]> Date: Wed, 24 Sep 2008 16:01:57 +0200 Subject: [PATCH] add new module filevercmp * lib/filev

Re: [PATCH] add new module filevercmp

", "0") < 0); */ > > Likewise. I removed both of them completely since there are a bit confusing in the context of filevercmp. It ignores leading zeros and if the versions are equal, strcmp is used to distinguish theirs (deterministic) order. Hopefully I didn't forget

Re: [PATCH] add new module filevercmp

Hello Bruno, thank you for review. I've attempted to cover all your suggestions. On Thursday 25 September 2008 02:18:50 Bruno Haible wrote: > Some systems still don't have C99 compilers. Therefore you cannot use > variable declarations after statements. Either collect the variable > declarations

Re: [PATCH] add new module filevercmp

GIT(c) ((unsigned int) (c) - '0' <= 9) Hopefully final version of the patch, copyright assignment left as TODO in the source code. Patch for coretuils ls and sort should be simple, I'll send it on Monday. Kamil From 0a584ead92d6c17cbf6b8cb133369da1906cae43 Mon Sep 17 00:00:

Re: willing to contribute verrevcmp to gnulib?

On Monday 29 September 2008 16:12:18 Ian Jackson wrote: > And which files are we talking about ? lib/vercmp.c > NB that the dpkg comparison algorithm was recently extended to support > a new character ~ which sorts before the empty string. This work > wasn't done by me - but I approve of it and i

Re: willing to contribute verrevcmp to gnulib?

On Tuesday 30 September 2008 12:13:08 Ian Jackson wrote: > Sorry, I overlooked this message before. Now I'm really confused. > You seem to have already rewritten it. So why are people asking for > permission and/or copyright assignment ? The core of filevercmp module is the verrevcmp function tak

Re: filevercmp: please post final filevercmp

(from Bruno's reply) - add verrevcmp function description (as Ian suggested) - use c_isdigit from c_ctype.h Kamil From bca1eacf955636d96913c2d6e2fedf29f0a8a6d7 Mon Sep 17 00:00:00 2001 From: Kamil Dudka <[EMAIL PROTECTED]> Date: Fri, 3 Oct 2008 10:31:28 +0200 Subject: [PATCH] add new module

Re: filevercmp: please post final filevercmp

On Friday 03 of October 2008 09:55:40 Jim Meyering wrote: > Please review these small changes that I expect to fold into your change > set: - use c_isdigit, c_isalpha, c_isalnum directly; no need for casts - Sorry, but I am not sure here. This was Bruno's suggestion from http://lists.gnu.org/archiv

Re: strage behaviour of ulimit

On Wednesday 26 November 2008 08:54:29 Andreas Klein wrote: > Hello. > > I have found the following strange bahavoiur of ulimit. > > As normal user I can increase the stack size once but not twice: > > [EMAIL PROTECTED]:~$ ulimit -s > 8192 > [EMAIL PROTECTED]:~$ ulimit -s 2 You are setting the

[PATCH] filevercmp: fix regular expression of file suffix

expression matching file suffix - there must be [^.] before suffix. Kamil From 595a83946c9846730c246321e043f03ec0653c15 Mon Sep 17 00:00:00 2001 From: Kamil Dudka Date: Fri, 27 Feb 2009 14:56:19 +0100 Subject: [PATCH] filevercmp: fix regular expression of file suffix * lib/filevercmp.c (match

Re: [PATCH] filevercmp: fix regular expression of file suffix

Hello Bruno, thanks for review! On Friday 27 of February 2009 17:02:56 Bruno Haible wrote: > As I understand it, the patch does not fix two things that were mentioned > negatively by Sven: > - that hidden files appear at the end, rather than at the beginning, Well, I don't know which order is "

[PATCH] filevercmp: move hidden files up in ordering

Hello, I've completely rewritten the patch for filevercmp. Now it is easier and gives "better" results. Please have a look at tests/test-filevercmp.c for expected ordering which covers most of cases. Kamil From 495b5d95ddca27efd31929df358c3749965691e7 Mon Sep 17 00:00:00 2001 Fr

Re: ls -v is still inconsistent

x27;t match any suffix containing '~'. I've changed it this way: /(\.[A-Za-z][A-Za-z0-9]*)*$/ /(\.[A-Za-z~][A-Za-z0-9~]*)*$/ Now it works correctly with simple and numbered backups. Simple patch including clarifying test cases is attached. Kamil From d889021cebb7bf798d1b7bf241

Re: ls -v is still inconsistent

On Friday 20 of March 2009 12:36:38 Bruno Haible wrote: > Jim Meyering wrote: > > Perhaps "~" isn't the only character we should treat that way. > > I'd say that '~' is pretty special here because it's used as backup file > suffix by many text editors. Which is not the case for '_', '-', and > othe

Re: ls -v is still inconsistent

On Friday 20 of March 2009 22:25:30 Bob Proulx wrote: > Kamil Dudka wrote: > > On Friday 20 of March 2009 12:36:38 Bruno Haible wrote: > > > Jim Meyering wrote: > > > > Perhaps "~" isn't the only character we should treat that way. > > > >

Re: ls -v is still inconsistent

On Saturday 21 March 2009 00:03:30 Kamil Dudka wrote: > On Friday 20 of March 2009 22:25:30 Bob Proulx wrote: > > The '~' is often used in package version numbers. It sorts before the > > version without it. For example the rule[1] for generating a stable > > ba

Re: ls -v is still inconsistent

On Tuesday 24 of March 2009 22:15:59 Jim Meyering wrote: > Jim Meyering wrote: > > Kamil Dudka wrote: > >> From d889021cebb7bf798d1b7bf24149c354627e9553 Mon Sep 17 00:00:00 2001 > >> From: Kamil Dudka > >> Date: Fri, 20 Mar 2009 11:20:12 +0100 > >&g

Re: Installing gnulib from git

On Wednesday 01 of April 2009 21:32:36 Reuben Thomas wrote: > On Wed, 1 Apr 2009, Mike Frysinger wrote: > > the `git clone` is the install. just execute the gnulib-tool script from > > there. > > Right. So I just add the directory to my PATH? Or symlink gnulib-tool into > a directory on my PATH?

Re: ls -v oddity with autosave files

On Thursday 09 April 2009 09:23:37 Sven Joachim wrote: > Note that the #.b# file is listed at the top in (1) and at the bottom in > (2), despite all filenames in the directory being the same! Thanks for discovering this! The transitive axiom of the predicate is broken. I am working on a fix. It s

Re: ls -v oddity with autosave files

On Thursday 09 April 2009 11:32:58 Kamil Dudka wrote: > On Thursday 09 April 2009 09:23:37 Sven Joachim wrote: > > Note that the #.b# file is listed at the top in (1) and at the bottom in > > (2), despite all filenames in the directory being the same! > > Thanks for

Re: ls -v oddity with autosave files

ou want to merge the tests, the second patch does it. Kamil From 079b6a1e5997fd0f42fe824b0e02861b78c6e9c6 Mon Sep 17 00:00:00 2001 From: Kamil Dudka Date: Thu, 9 Apr 2009 18:07:15 +0200 Subject: [PATCH] filevercmp: fix regression --- lib/filevercmp.c | 11 +++ 1 files changed, 11

Re: [PATCH 1/2] find: add SELinux support

On Thu August 6 2009 12:36:06 Kamil Dudka wrote: > On Thu August 6 2009 12:16:58 Jim Meyering wrote: > > Kamil Dudka wrote: > > > On Thu July 30 2009 13:57:00 Jim Meyering wrote: > > >> > The attached incremental patch fixes it. Now it works on both Fedora > >

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

Re: FTS not ready for a remount during traversal

Hi Jim, thanks for quick reply! On Wednesday 21 of October 2009 21:47:59 Jim Meyering wrote: > It fails for a very good reason. > A changed device number may indicate an attempt to subvert the traversal, > even though the inode number is the same. I agree. > > https://bugzilla.redhat.com/attach

Re: Issue with ls -v / sort -V and strverscmp() usage

or handling version sort (like > rpmvercmp in recommended in glibc strverscmp() bugzilla) > > Which way do you like? Or do you have different ideas? > > Greetings, > Ondrej Vasik From 321dede6df5a2df1a5a54b65ba5755e7767832a1 Mon Sep 17 00:00:00 2001 From: Kamil Dudka &

Re: Issue with ls -v / sort -V and strverscmp() usage

On Thursday 04 September 2008 00:52:08 you wrote: > We cannot take this patch, as the gnulib strverscmp function is meant to be > a substitute for the glibc function of the same name. (Sorry, the doc was > not clear about it until today.) This means, gnulib's strverscmp needs to > behave the same a

Re: Issue with ls -v / sort -V and strverscmp() usage

On Sunday 07 September 2008 08:28:11 Jim Meyering wrote: > IMHO, changing sort -V to produce more intuitively-correct results > is the way to go. > > With ls -v, I'm willing to make the change as well, *assuming* > no one produces a counterargument. > > The question is what ordering function to use

Re: Issue with ls -v / sort -V and strverscmp() usage

Hello Bruno, thanks for excellent review. When the function's behavior is definitely accepted by people here, I will improve its implementation. On Wednesday 17 September 2008 13:13:03 you wrote: > There are still a few things to do before we can add it to gnulib: > - Do you have a copyright a

Re: Issue with ls -v / sort -V and strverscmp() usage

On Wednesday 17 September 2008 13:13:03 you wrote: > - Fix the obvious bugs, for example, you need to cast 'char' values to > 'unsigned char' before passing them to functions. > - Streamline the operation: Can't you get rid of copying the two strings? > For example, by changing verrevc

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

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

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

[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: [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] 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: 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

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

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

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

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

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

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

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

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: 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: 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: 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 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 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 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 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 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: 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: [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: [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: 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: 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 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 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: [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: [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] 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 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] 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] 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: 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: 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

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

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

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

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

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

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

[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

[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

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(

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

  1   2   >