[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bugfix: Failure of -execdir to process arguments at depth 0

From: Dmitry V. Levin
Subject: Re: Bugfix: Failure of -execdir to process arguments at depth 0
Date: Sun, 6 Feb 2005 19:20:28 +0300


On Sat, Feb 05, 2005 at 12:19:55PM +0000, James Youngman wrote:
> I have now checked into CVS a change which properly resolves the
> problem, much as described below.
> > One option is for process_top_path to change working directory to the
> > parent directory of the item to be processed (unless
> > (0==strcmp(pathname,"."))).  However, this is nontrivial to implement
> > correctly since pathname might be "../../../.." for example.  Also the
> > named argument might be a directory which is searchable by the current
> > user, while its parent might not.
> In fact it does turn out to be trivial to implement.  In the case
> where the argument was actually "../../../../", then we chdir to
> "../../.." and so "./.." is passed as the value of {} in the -execdir
> implementation.  Hence we don't need to be in the parent directory
> under all circumstances, and are in effect following the same "route"
> to the named file as lstat() does, for example.  Therefore I think
> there won't be any corner cases around inaccessible directories.

Unfortunately, they are.

Imagine this test case:
$ mkdir dir1
$ mkdir dir1/dir2
$ touch dir1/dir2/foo
$ ln -s dir1 link1
$ find-4.2.15 link1/dir2 -type f
$ find-4.2.16 link1/dir2 -type f
find: link1
$ find-4.2.16 -H link1/dir2 -type f

This happens because of "find -P" (never follow symbolic links) is the
default behaviour, and starting point "link1" is symlink while starting
point "link1/dir2" is not.

You can try to fix this bug by temporarily allowing to follow symlinks
during this "first chdir" in process_top_path(), but I'm not certainly


Attachment: pgpESkSQq6puL.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]