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

[James Youngman]

On Thu, Feb 03, 2005 at 11:23:26PM +0000, James Youngman wrote:

> I have put in place (in CVS) a quick fix for the problem.  It makes
> -execdir work the same as -exec when (state.curdepth==0).  The problem
> is that the working directory at that point will still be the same as
> it was when we started, as we have not recursed into any directories
> yet.
> 
> If you have a good suggestion as to how this should be better solved,
> please let me know.

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.

In my investigation of the problem I decided to find out what FreeBSD
"find" does in the same situation (i.e. was my earlier 'quick fix'
what FreeBSD actually does?).  I believe that it turns out that
FreeBSD actually had the same bug(!).


Regards,
James.