[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 |
Hi,
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
link1/dir2/foo
$ find-4.2.16 link1/dir2 -type f
find: link1
$ find-4.2.16 -H link1/dir2 -type f
link1/dir2/foo
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
sure.
--
ldv
pgpESkSQq6puL.pgp
Description: PGP signature
- [patch] find/pred.c: basename versus base_name., Bas van Gompel, 2005/02/02
- Re: [patch] find/pred.c: basename versus base_name., Dmitry V. Levin, 2005/02/02
- Re: [patch] find/pred.c: basename versus base_name., Bas van Gompel, 2005/02/03
- Re: [patch] find/pred.c: basename versus base_name., Dmitry V. Levin, 2005/02/03
- Re: [patch] find/pred.c: basename versus base_name., Bas van Gompel, 2005/02/03
- Re: [patch] find/pred.c: basename versus base_name., James Youngman, 2005/02/03
- Bugfix: Failure of -execdir to process arguments at depth 0, James Youngman, 2005/02/05
- Re: Bugfix: Failure of -execdir to process arguments at depth 0, Bas van Gompel, 2005/02/05
- Re: Bugfix: Failure of -execdir to process arguments at depth 0, Dmitry V. Levin, 2005/02/05
- Re: Bugfix: Failure of -execdir to process arguments at depth 0, James Youngman, 2005/02/06
- Re: Bugfix: Failure of -execdir to process arguments at depth 0,
Dmitry V. Levin <=
- Re: Bugfix: Failure of -execdir to process arguments at depth 0, James Youngman, 2005/02/06
Re: [patch] find/pred.c: basename versus base_name., James Youngman, 2005/02/02