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
The only thing I'd add to that is to suggest using a high value like 0x4000
for FTS_NOLEAF.
On 07/27/2017 06:23 AM, James Youngman wrote:
> Looking at the patch, it looks not terribly burdensome to maintain
> "downtream" except for the possibility that some fts option could
> subsequently be introduced in gnulib which shares a value with
> FTS_NOLEAF.
>
> Paul, since you don't plan to ap
Looking at the patch, it looks not terribly burdensome to maintain
"downtream" except for the possibility that some fts option could
subsequently be introduced in gnulib which shares a value with
FTS_NOLEAF.
Paul, since you don't plan to apply this patch upstream, do you have
any suggestions for e
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 are available.
>
> My cha
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 are available.
My changes fixed some bugs and did not affect the fts API. Your changes would
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 can still support
> -noleaf ev
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 can still support -noleaf
even when using unmodified Gnulib. Just have -noleaf turn off FTS_CW
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 extra option to disable an optim
James Youngman wrote:
I don't see FTS_CURDIR in fts_.h. Is that the right enum name?
Sorry, I meant FTS_CWDFD.
On Tue, Jul 25, 2017 at 5:10 PM, 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 extra option to disable an o
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 extra option to disable an optimization that is
supposed to work.
As things stand, 'find' ca
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
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
should affect findutils and coreutils are minor performance p
14 matches
Mail list logo
