[bug #61327] Support for birth time

Follow-up Comment #3, bug #61327 (project findutils): > This directive produces an empty string if the underlying > operating system or filesystem does not support birth times. I do not think the above statement is accurate. On Linux, `find -printf %BT` produces empty string even if the operatin

Re: findutils-4.8.0-2.fc34.x86_64

On Tuesday, August 31, 2021 11:26:15 AM CEST Ricky Tigg wrote: > Tested on Fedora; findutils-4.8.0-2.fc34.x86_64 > > Hello.As noticeable in output resulting from 'find -name > ""'' , paths are duplicated. > > $ find /usr/share/icons/ -name "battery*" | head -1 > /usr/share/icons/Adwaita/16x16/d

Re: [PATCH] find.1: avoid misunderstanding of `-prtinf %Ak` description

On Wednesday, October 7, 2020 12:36:56 AM CEST Bernhard Voelker wrote: > Hi Kamil, > > On 2020-10-06 17:10, Kamil Dudka wrote: > > * find/find.1 (-printf): Make it clear that strftime() format > > description in this man page is incomplete and refer to the > > strft

[PATCH] find.1: avoid misunderstanding of `-prtinf %Ak` description

* find/find.1 (-printf): Make it clear that strftime() format description in this man page is incomplete and refer to the strftime() documentation instead. Suggested in https://bugzilla.redhat.com/1882695 --- find/find.1 | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/fin

[bug #57762] Test fail of find.posix/sv-bug-54171.exp

Follow-up Comment #2, bug #57762 (project findutils): This was also reported in Red Hat Bugzilla: https://bugzilla.redhat.com/1799064 The proposed patch works for me: The test is now skipped when running with root privileges. Thank you for taking care of it!

[PATCH] find -samedev NAME: true for files on the same device as NAME

There is no easy way to exclude mount points from the output of `find`. The options -xdev or -mount prevent `find` from traversing over the mount points but do not exclude the mount points themselves. It could be scripted by AWK on Linux as in the following example: $ find / -xdev -maxdepth 1 $(a

[bug #54591] gnulib components in findutils do not compile with glibc 2.28

Follow-up Comment #5, bug #54591 (project findutils): I agree but I am not the one who schedules releases here. ___ Reply to this item at: ___ Message s

[bug #54591] gnulib components in findutils do not compile with glibc 2.28

Follow-up Comment #3, bug #54591 (project findutils): ... and the other error was fixed by http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=4af4a4a7 ___ Reply to this item at: ___

[bug #54591] gnulib components in findutils do not compile with glibc 2.28

Follow-up Comment #2, bug #54591 (project findutils): This was fixed by http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=4da63c58 but there was no release of findutils since then. ___ Reply to this item at:

Re: [bug #54509] `-execdir command ;` returns 0 when it should not

On Tuesday, August 14, 2018 10:43:44 PM CEST Bernhard Voelker wrote: > Update of bug #54509 (project findutils): > > Status:None => In Progress > Assigned to:None => berny > > __

Re: next release version of findutils?

ntly in the master branch) Kamil > When the new version comes out I will update the conda recipe. > > Again, thank you for your help. > > Best, > > Karl > > On 09.08.2018 08:40, Kamil Dudka wrote: > > On Thursday, August 9, 2018 8:30:39 AM CEST Bernhard

Re: next release version of findutils?

On Thursday, August 9, 2018 8:30:39 AM CEST Bernhard Voelker wrote: > On 08/08/2018 09:49 AM, Karl Nordström wrote: > > Hi, > > > > I wanted to ask whether there is a new release for findutils comming up? > > > > I want to add it to conda-forge and am having trouble passing make > > check. Partly

Re:

On Sunday, July 22, 2018 10:09:49 PM CEST James Youngman wrote: > On Thu, Jul 12, 2018 at 10:37 PM, Jonathan M. Wilbur > > wrote: > > “find: ../../find/util.c:297: get_info: Assertion `p->st_ino' failed.” > > Let's start by checking the symptom directly. Assuming the problem > is easily reprod

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 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] find: properly support -noleaf in ftsfind.

On Saturday, September 2, 2017 5:35:31 PM CEST James Youngman wrote: > * gnulib-local/lib/fts.c.diff: incorporated from a patch by Kamil > Dudka . This patch introduces an FTS_NOLEAF option > to fts. > * gnulib-local/lib/fts_.h.diff: Likewise. > * find/ftsfind.c (ftsoptions):

Re: SIGSEGV in partial_quotearg_n()

On Monday, August 28, 2017 11:51:08 PM CEST Bernhard Voelker wrote: > On 08/18/2017 04:23 PM, Kamil Dudka wrote: > > We have multiple occurrences of automated crash reports: > > > > https://retrace.fedoraproject.org/faf/reports/1209278/ > > > > ... about SIGSEG

[bug #51841] find buffer-overflow with -printf '%T+'

Follow-up Comment #1, bug #51841 (project findutils): I think that both the bug and the fix are obvious. After the mentioned patch, the code writes 12 bytes into a stack-allocated array of size 6 bytes: char fmt[6]; // [...] /* Format the main part of the time. */ if (kind == '+')

SIGSEGV in partial_quotearg_n()

We have multiple occurrences of automated crash reports: https://retrace.fedoraproject.org/faf/reports/1209278/ ... about SIGSEGV in partial_quotearg_n() at this location in the source code: http://git.savannah.gnu.org/cgit/findutils.git/tree/find/ftsfind.c?h=v4.6.0#n219 I guess it crashes beca

Re: Fwd: help us to resolve this command

On Friday, August 11, 2017 16:17:30 Aman ulla wrote: > how can i run this command in our centos 7 server to get results..? It depends on which results you want to get. My suggestion is not to run commands as root unless you really understand what they do ;-) > # find /root/home/ -mindepth 1 -ty

Re: Several changes made to fts.c in Gnulib

On Friday, July 28, 2017 11:38:12 Paul Eggert wrote: > The only thing I'd add to that is to suggest using a high value like > 0x4000 for FTS_NOLEAF. I am fine with my current patch. If gnulib upstream introduces new flags later on, it will be not that difficult to find a free bit for FTS_NOL

Re: Several changes made to fts.c in Gnulib

On Wednesday, July 26, 2017 09:31:47 Paul Eggert wrote: > Kamil Dudka wrote: > > You even admitted that they could have introduced new bugs. Now you are > > refusing to push a tiny commit that would significantly help to debug them > > in environments where only binaries a

Re: Several changes made to fts.c in Gnulib

On Tuesday, July 25, 2017 20:26:43 Paul Eggert wrote: > Kamil Dudka wrote: > > While I respect your opinion about removing this debugging facility > > upstream, the -noleaf option stays implemented in Fedora. > > That shouldn't be a problem. As I mentioned, findutils c

Re: Several changes made to fts.c in Gnulib

On Tuesday, July 25, 2017 09:10:09 Paul Eggert wrote: > Kamil Dudka wrote: > > Any chance to make the (still documented) -noleaf option of find work > > again? > I'm inclined to agree with Pádraig, in thinking that fts should Just Work > without the complexity of an

Re: Several changes made to fts.c in Gnulib

On Tuesday, July 25, 2017 02:16:30 Paul Eggert wrote: > I found some subtle bugs in Gnulib fts.c, and created a test case that > reliably fails in reiserfs due to confusion with st_nlink. I added this > test case to Gnulib and fixed the bugs I found. As far as I can see, the > only problems that sh

Re: [bug #51345] find shows different results despite using same command

On Wednesday, July 05, 2017 16:01:53 James Youngman wrote: > Follow-up Comment #4, bug #51345 (project findutils): > > Try again, passing also the option -noleaf to find. The -noleaf option of find is silently ignored if find is built with FTS. I proposed a gnulib patch that would allow us to mak

Re: "find: '/usr/...': Too many open files" when using -execdir

On Saturday, June 03, 2017 09:03:54 Dale R. Worley wrote: > I know I've seen something about this before: When I use -execdir, I > get a message like: > > find: '/usr/share/texlive/texmf-dist/tex4ht/ht-fonts/alias/kurier/sy-iwona': > Too many open files find: Failed to save working directory in o

[bug #48030] -exec + does not pass all arguments for certain specific filename lengths

Follow-up Comment #7, bug #48030 (project findutils): Looks good to me. I can confirm it fixes the problem. As a minor nit, there are two trailing white-spaces in the test case. ___ Reply to this item at:

Re: [bug #48030] -exec + does not pass all arguments for ceratin specific filename lengths

On Friday, May 27, 2016 12:37:27 anonymous wrote: > Follow-up Comment #2, bug #48030 (project findutils): > > Is this bug reproducible with the current stable release (4.6.0)? It is reproducible with 4.6.0 as well as the current upstream git HEAD: v4.6.0-64-g85e8c81 Kamil

Re: [PATCH] clarify exit status handling of -exec command {} +

On Sunday, April 17, 2016 22:46:22 Bernhard Voelker wrote: > On 04/13/2016 03:07 PM, Kamil Dudka wrote: > > * find(-exec): Explain how exit status is propagated if the > > -exec command {} + syntax is used. > > > > Reported at https://bugzilla.redhat.com/1325049 > &

[PATCH] clarify exit status handling of -exec command {} +

* find(-exec): Explain how exit status is propagated if the -exec command {} + syntax is used. Reported at https://bugzilla.redhat.com/1325049 --- find/find.1 | 3 +++ 1 file changed, 3 insertions(+) diff --git a/find/find.1 b/find/find.1 index c948b4b..2c228f8 100644 --- a/find/find.1 +++ b/fin

Re: stable branches (was Re: [PATCH 0/8] maintenance patches)

On Tuesday, January 05, 2016 17:28:03 James Youngman wrote: > On Tue, Jan 5, 2016 at 1:31 PM, Kamil Dudka wrote: > > On Monday 04 January 2016 15:17:24 James Youngman wrote: > >> c) I'd like input from the other committers and from the principal > >> downstrea

stable branches (was Re: [PATCH 0/8] maintenance patches)

On Monday 04 January 2016 15:17:24 James Youngman wrote: > c) I'd like input from the other committers and from the principal > downstream consumers (e.g. Andreas, Kamil) before making a choice, > since it's the committers who would need to maintain the parallel > branches and the downstream mainta

Re: Allow `find` to use exported function for -exec*?

On Thursday 16 April 2015 23:20:06 Dale R. Worley wrote: > Eric Blake writes: > > On 04/15/2015 08:50 PM, Peng Yu wrote: > >> Hi, It seems that it might be convenient to allow `find` to use > >> exported functions from shell for -exec*? Can this feature be added in > >> the future? > > > > If you

[bug #44221] Spurious warning about non-option arguments is spurious

Follow-up Comment #3, bug #44221 (project findutils): That might be true in your simple case, but it does not hold in general. What about the following command for instance? find -type f -ls -a -mindepth 4 -delete ___ Reply to this item a

[bug #44221] Spurious warning about non-option arguments is spurious

Follow-up Comment #1, bug #44221 (project findutils): -mindepth and -maxdepth are options whereas -type is a test. You need to specify options before non-optionos (tests and actions). ___ Reply to this item at:

Re: Announcing the release of GNU findutils 4.5.12

download > this from http://savannah.gnu.org/users/jay. Please note that the key > being used is not the same as the key that was used to sign previous > releases. > > I'd like to thank the following people for their contributions to this > release: > > Andreas Metzler &

Re: I need help to use find and curl together to upload a directory

On Tuesday 13 August 2013 01:35:02 Christoph Roland Murauer wrote: > Am 12.08.2013 um 18:46 schrieb James Youngman : > > I don't clearly understand the problem you are trying to describe (you > > might find it helpful to review > > http://www.catb.org/esr/faqs/smart-questions.html). Are you sayin

Re: [PATCH] Prevent 'make clean' from removing git-tracked files in lib/.

On Sunday, March 24, 2013 14:13:23 James Youngman wrote: > Thanks for the patch. However, since we used the same idiom elsewhere > in the code, I thought that a more extensive change was justified. I > committed the fix as > http://git.savannah.gnu.org/cgit/findutils.git/commit/?id=a917eb988fab8

[PATCH] Prevent 'make clean' from removing git-tracked files in lib/.

/ChangeLog index d96adc0..18e44f0 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2013-02-04 Kamil Dudka + + Prevent 'make clean' from removing git-tracked files in lib/. + * lib/Makefile.am (libfind_a_SOURCES): Move header files to EXTRA_DIST + in order not t

[PATCH v2 3/3] Fix compile-time warnings.

+- xargs/xargs.c |2 +- 7 files changed, 19 insertions(+), 19 deletions(-) diff --git a/ChangeLog b/ChangeLog index 7781742..d96adc0 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,14 @@ 2013-02-03 Kamil Dudka + Fix compile-time warnings. + * find/defs.h (struct predicate

Re: [PATCH 3/3] Fix compile-time warnings.

On Sunday 03 February 2013 23:07:42 Kamil Dudka wrote: > diff --git a/find/exec.c b/find/exec.c > index aa69fe3..f731d82 100644 > --- a/find/exec.c > +++ b/find/exec.c > @@ -324,7 +324,7 @@ launch (struct buildcmd_control *ctl, void > *usercontext, int

[PATCH 1/3] Eliminate a misleading message of import-gnulib.sh

ff --git a/ChangeLog b/ChangeLog index 5bdc656..c61da2e 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2013-02-03 Kamil Dudka + + Eliminate a misleading message of import-gnulib.sh on a fresh + repository obtained by 'git clone --recursive'. +

[PATCH 3/3] Fix compile-time warnings.

deletions(-) diff --git a/ChangeLog b/ChangeLog index d7476d5..e56e289 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,14 @@ 2013-02-03 Kamil Dudka + Fix compile-time warnings. + * find/defs.h (struct predicate): Add a missing const modifier. + * find/exec.c (launch): Add

[PATCH 2/3] Avoid using 'INCLUDES =' in automake templates.

/Makefile.am |2 +- 5 files changed, 10 insertions(+), 4 deletions(-) diff --git a/ChangeLog b/ChangeLog index c61da2e..d7476d5 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,11 @@ 2013-02-03 Kamil Dudka + Avoid using 'INCLUDES =' in automake templates. + * find/M

Re: Questions about how to use git

On Sunday 03 April 2011 16:15:22 Kai YU wrote: > Yes, I also guess that I have to use the equally old gnulib. The problem is > I can use git to switch to the old version of findutils, but I don't know > how to obtain the corresponding old snapshot of gnulib. In case of up2date findutils, the infor

Re: Questions about how to use git

On Saturday 02 April 2011 19:54:48 Kai YU wrote: > Hi, I'm currently investigating how to fight software regressions with > git bisect. Particularly, I want to use git bisect to help locate the > #Bug12181 (http://savannah.gnu.org/bugs/?12181). However, when I use "git > checkout FINDUTILS_4_2

Re: [PATCH v2] backport of patches for upstream bugs #19593 and #27563

On Saturday 02 April 2011 17:16:11 James Youngman wrote: > (resending, this time omitting the large patch with the .po file changes) > > I noticed today I had not done this.   Sorry! > > I needed to add an extra few patches to: > - update the version of gnulib and fix a dependency problem > - fix t

[bug #29949] find -execdr does not change working directory

Additional Item Attachment, bug #29949 (project findutils): File name: 0001-Fix-Savannah-bug-29949-execdir-does-not-change-worki.patch Size:2 KB ___ Reply to this item at:

Re: backport of patches for upstream bugs #19593 and #27563

On Monday 17 of May 2010 23:59:11 James Youngman wrote: > Unfortunately I think something went a little wrong with the rebase > (or whatever you did). When I apply your patches against > rel-4-4-fixes (a242875ae63167ee29c3f626741c56266be3bc92) and do "make > distcheck" I get this output: Sorry f

Re: [PATCH] fix bugs in run_in_dir ()

On Friday 07 of May 2010 10:56:52 Kamil Dudka wrote: > > If you'd like to supply a backported "format-patch" patch against the > > 4.4.x tree, I can apply that too. > > It may sound stupid, but where can I get the upstream 4.4.x branch from? Hopefully I got the ri

Re: [PATCH] fix bugs in run_in_dir ()

On Friday 07 of May 2010 10:08:08 James Youngman wrote: > Thanks for spotting this. I can see the bug simply by inspecting > your fix. But, is there any kind of test case which actually > demonstrates the problem? If we add a relevant test we can protect > ourselves against reintroducing this

Re: [PATCH] fix bugs in run_in_dir ()

On Friday 07 of May 2010 10:41:03 James Youngman wrote: > I have applied and pushed your patch as the two attached git patches > (if you could send your changes in "git format-patch" format in > future, ideally with a ChangeLog entry too, that would streamline > things for me). Sure, will do. > >

Re: [PATCH] fix bugs in run_in_dir ()

On Thursday 06 of May 2010 15:03:32 Kamil Dudka wrote: > Hello, > > attached is a patch fixing bugs of run_in_dir () which I encountered while > doing backport of #19593 for stable findutils. Thanks in advance for > considering the patch! Folow-up: diff --git a/lib/dirc

[PATCH] fix bugs in run_in_dir ()

Hello, attached is a patch fixing bugs of run_in_dir () which I encountered while doing backport of #19593 for stable findutils. Thanks in advance for considering the patch! Kamil diff --git a/lib/dircallback.c b/lib/dircallback.c index 8497bee..ed36ee2 100644 --- a/lib/dircallback.c +++ b/lib

Re: How to find directories or symbolic links that point to directories?

On Monday 03 of May 2010 18:39:38 Peng Yu wrote: > I know -type d is for directory. But how to find directory as well as > symbolic links that point to directories? Have you tried 'find -L'? Kamil

Re: assertion failures of findutils 4.5.7

On Monday 05 of April 2010 22:01:22 James Youngman wrote: > I attach a set of patches. They're the same as the patches I emailed > yesterday, but rebased against current head. The patches look good! I've applied all of them and built as findutils-4.5.7-4.fc14. Thanks! Kamil

Re: assertion failures of findutils 4.5.7

On Monday 05 of April 2010 22:24:18 Kamil Dudka wrote: > On Monday 05 of April 2010 22:01:22 James Youngman wrote: > > This is a known problem, Savannah bug #27213. Yesterday, I mailed > > patches to the list which should fix this. See > > Mailed where actually? I so

Re: assertion failures of findutils 4.5.7

On Monday 05 of April 2010 22:01:22 James Youngman wrote: > This is a known problem, Savannah bug #27213. Yesterday, I mailed > patches to the list which should fix this. See Mailed where actually? I somehow missed them and still don't see any beyond this mail... The only patch I encountered

assertion failures of findutils 4.5.7

Hello, Sami Farin (CC'd) discovered some flaws in recent findutils and reported them at Red Hat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=579476#c0 https://bugzilla.redhat.com/show_bug.cgi?id=579476#c2 Here are proposed patches: https://bugzilla.redhat.com/attachment.cgi?id=404487 ht

[bug #29435] fd_is_cloexec () does not work on Fedora buildhosts

Follow-up Comment #3, bug #29435 (project findutils): Great! built for Fedora as findutils-4.5.7-3.fc14 http://koji.fedoraproject.org/koji/buildinfo?buildID=165369 ___ Reply to this item at:

Re: fd_is_cloexec () does not work on Fedora buildhosts

On Sunday 04 of April 2010 02:10:13 James Youngman wrote: > I suspect what's happening is that the library on your build hosts > defined O_CLOEXEC, but your kernel lacks support for it. fcntl(fd, > F_GETFL) may just return the original flags we passed, meaning that > it's not a guarantee that the

fd_is_cloexec () does not work on Fedora buildhosts

Hello, thanks for the new release of findutils in the first place! While I was trying to build packages for Fedora, I ran into huge test-suite failure. For merely all tests the assertion within complain_about_leaky_fds () failed on the descriptor 3 or 4. Poking around, I discovered the functi

Re: [PATCH 2/2] Bugfixes to the handling of %Z in the Red Hat SELinux patch.

On Tue March 30 2010 11:34:59 James Youngman wrote: > Sorry, this slipped off my radar. I have pushed the change now. > That means it will be included in findutils-4.5.6, when that is > released. Thank you for getting the patch in! I'll keep following the mailing-list for eventual issues relate

[bug #29089] SELinux --context and %Z options

Follow-up Comment #1, bug #29089 (project findutils): The bug is already filled at: https://savannah.gnu.org/patch/?4848 Latest git patches available at: http://lists.gnu.org/archive/html/bug-findutils/2009-11/msg00033.html ___ Reply to

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

re > on some less common system, etc.). is there any schedule to get this in? Attached are the patches rebased against current HEAD. I only moved the ChangeLog entries up. Kamil From 88f7591275265f72d1f741ed05e2af4b1c2329d6 Mon Sep 17 00:00:00 2001 From: Kamil Dudka Date: Thu, 26 Nov 2009 11:55

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: [PATCH 1/2] find: add SELinux support

On Thu August 6 2009 18:15:28 Jim Meyering wrote: > Kamil Dudka wrote: > > Thanks for the quick response. An incremental patch is attached for > > review. I'll merge it with the original patch if the change is ok. > > I glanced through quickly, and didn't see anythin

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

On Thursday 06 of August 2009 14:01:37 Jim Meyering wrote: > ... > > >> I'll move them to gnulib. > > > > Thanks! > > > > Just let me note there is no explicit dependency on the openat module > > (namely lib/at-func.c). Is the dependency implied somehow? > > Good point. > I'll add that module depen

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

On Thu August 6 2009 13:23:38 Jim Meyering wrote: > 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 fix

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

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

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 > >> > and Debian. But unfortunately it does not work with the

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

On Thu July 30 2009 13:57:00 Jim Meyering wrote: > > The attached incremental patch fixes it. Now it works on both Fedora and > > Debian. But unfortunately it does not work with the stable version > > (4.4.2) of findutils. Could anybody point me to the relevant change in > > findutils code? Thanks

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

On Mon July 20 2009 13:33:23 Kamil Dudka wrote: > Sorry for confusion. My previous testing was completely wrong because I ran > older version of findutils on Fedora. With the current git version it fails > on Fedora, too. It means something has been changed within findutils and/or > g

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

On Tue July 14 2009 21:31:22 Eric Blake wrote: > Kamil Dudka redhat.com> writes: > > In other words on Debian find does not change the working directory > > before calling lgetxattr syscall. That's why lgetxattr does not see the > > file and returns ENOENT (No suc

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

On Tue July 14 2009 14:02:36 Kamil Dudka wrote: > attached are strace outputs from Fedora and Debian. I can see one > suspicious place in that - this is the first main difference between Fedora > and Debian: Oops, once again: Fedora strace: open("m4", O_RDONLY|O_N

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

Hello, On Mon July 13 2009 17:48:15 Kamil Dudka wrote: > As time permits I will keep on trying to zero in this. attached are strace outputs from Fedora and Debian. I can see one suspicious place in that - this is the first main difference between Fedora and Debian: Fedora strace: open(

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

On Sat July 11 2009 18:10:49 James Youngman wrote: > On Sat, Jul 11, 2009 at 4:58 PM, Kamil Dudka wrote: > > Thanks for digging up the SELinux patch! > > No problem. From memory, I think the SELinux kernel support in > Debian doesn't play nicely with Xen. That means that

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

On Saturday 11 of July 2009 17:05:18 James Youngman wrote: > From: Kamil Dudka > > * find/defs.h: Add SELinux related definitions. > * find/tree.c: Add -context predicate to lookup. > * find/pred.c: Handle %Z printf directive. > * find/parser.c: Parse -context predicate and %

Re: [PATCH 2/2] Bugfixes to the handling of %Z in the Red Hat SELinux patch.

On Sunday 12 of April 2009 17:31:37 James Youngman wrote: > * find/pred.c (do_fprintf): If getfilecon fails, print the > relevant segment anyway, with the file context expanding to an > empty string. > * find/parser.c (make_segment): For %Z, set the cost to > NeedsAccessInfo. > > Signed-off-by: Jam

[patch #4848] Patch - Support for SELinux

Additional Item Attachment, patch #4848 (project findutils): File name: 0001-find-add-SELinux-support.patch Size:14 KB ___ Reply to this item at: ___

[patch #4848] Patch - Support for SELinux

Follow-up Comment #4, patch #4848 (project findutils): > * It does not update the Texinfo documentation at all! It does. The -context predicate is mentioned in 'info "Finding Files" "Mode Bits"' and the %Z printf conversion is mentioned in 'info "Actions" "Print File Information" "Format Directiv

[patch #4848] Patch - Support for SELinux

Additional Item Attachment, patch #4848 (project findutils): File name: 0001-find-add-SELinux-support.patch Size:14 KB ___ Reply to this item at: ___

[patch #4848] Patch - Support for SELinux

Additional Item Attachment, patch #4848 (project findutils): File name: 0001-Add-SELinux-support.patch Size:14 KB ___ Reply to this item at: ___ Messa

[PATCH] Add SELinux support

Mon Sep 17 00:00:00 2001 From: Kamil Dudka Date: Wed, 28 Jan 2009 15:00:34 +0100 Subject: [PATCH] Add SELinux support. * find/defs.h: Add SELinux definitions. * find/tree.c: Add -context predicate to lookup. * find/pred.c: Handle %Z printf directive. * find/parser.c: Parse -context predicate and %Z