[bug #20871] regression in oldfind when $PWD is inaccessible

Update of bug #20871 (project findutils): Status: In Progress => Fixed ___ Reply to this item at: ___

Re: [bug #15384] find misbehaves when parent directory is not readable

On 8/22/07, Eric Blake <[EMAIL PROTECTED]> wrote: > At this point, since we are about to create a stable 4.4 branch where the > fts()-based find works, do we still need to worry about the home-grown > oldfind, which still has the bug? Yes, for the time being, I think so. I believe that last time

[bug #20873] -path documentation should be clearer on "*" vs. "/" and "."

URL: Summary: -path documentation should be clearer on "*" vs. "/" and "." Project: findutils Submitted by: jay Submitted on: Wednesday 08/22/2007 at 21:52 Category: documentation

[bug #19899] find fails when it encounters irrelevant restrictions on $PWD

Update of bug #19899 (project findutils): Status:None => Need Info ___ Follow-up Comment #1: Is this still a problem in 4.3.8? Also, can you show the output of find --version, so we can

[bug #20871] regression in oldfind when $PWD is inaccessible

URL: Summary: regression in oldfind when $PWD is inaccessible Project: findutils Submitted by: ericb Submitted on: Wednesday 08/22/2007 at 12:19 Category: find Severit

[bug #15384] find misbehaves when parent directory is not readable

Update of bug #15384 (project findutils): Status:None => Fixed Fixed Release:None => 4.3.2 ___ Follow-up Comment #3: Actually, the fa

[bug #15384] find misbehaves when parent directory is not readable

Follow-up Comment #2, bug #15384 (project findutils): Revisiting this old bug, I wonder if the fts algorithm in 4.3.x matters. Anyways, while trying to reproduce this, I did: $ d=/tmp/.private/d $ mkdir -p $d $ chmod a-rx /tmp/.private $ dirname $d /tmp/.private $ find --version |head -n1 GNU f

[bug #20865] -delete interacts with -prune

Follow-up Comment #2, bug #20865 (project findutils): I was bit by this, too. Besides using -wholename, one can also just use -type f -exec rm -f {} ; It's hard to break a habit -- like using -delete -- after you start. It's more convenient writing -delete than the -exec statment, and I also f

[bug #20865] -delete interacts with -prune

Update of bug #20865 (project findutils): Status:None => Confirmed Release: 4.2.28 => 4.2.3 ___ Follow-up Comment #1: This has been pr

Re: updatedb: Spaces in {local,prune,net}paths

On 8/22/07, Bob Proulx <[EMAIL PROTECTED]> wrote: > With that caveat, would it be enough to use the same escapes that 'ls -b' > uses and accept that into the strings? That would make it easier to > cut and paste the result into the configuration file. It would also > allow keeping basically the s

[bug #20865] -delete interacts with -prune

URL: Summary: -delete interacts with -prune Project: findutils Submitted by: None Submitted on: Wednesday 08/22/2007 at 08:50 UTC Category: find Severity: 3 - Normal

Re: updatedb: Spaces in {local,prune,net}paths

On Wed, Aug 22, 2007 at 01:37:09AM -0600, Bob Proulx wrote: > With that caveat, would it be enough to use the same escapes that 'ls -b' > uses and accept that into the strings? That would make it easier to > cut and paste the result into the configuration file. It would also > allow keeping basi

Re: updatedb: Spaces in {local,prune,net}paths

James Youngman wrote: > James Youngman wrote: > > [EMAIL PROTECTED] wrote: > > > AFAICS there's no way to have directory names with spaces in the > > > mentioned paths. > > > > > > Shall we define one? > > > > I'm generally in favour. > ... > Pinging bug-findutils members for any comments I am