ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jaikiran Pai <>
Subject Re: FileUtils.normalize/isLeadingPath have bitten me
Date Thu, 28 Jun 2018 15:23:10 GMT

On 28/06/18 8:37 PM, Stefan Bodewig wrote:
> On 2018-06-28, Jaikiran Pai wrote:
>> However, looking at the FileUtils#isLeadingPath(...) implementation, I
>> wonder why it even uses normalize. Given that the goal of that API (as
>> stated in the javadoc) is to figure out if one path leads the other,
>> to me that translates to being a check to see whether the "leading"
>> param to that method is a parent of the "path". I suppose that can be
>> implemented by using the call on each
>> of the params and then doing a iterative getParent() call on the
>> canonical File returned for the "path" and seeing if it ends up
>> leading to the canonical File returned for "leading". The call to
>> should take care of the ".", ".." and
>> even symbolic link reference resolutions (which I guess is a good
>> thing?).
> I think I have written that method long ago so I should be able to
> answer that. Unfortunately I'm not.
> In may cases we did not want to resolve canonical paths. I think the
> expectation is that for
> /dir
>    /dir2
>    /dir3
>       link -> /dir/dir2
> isLeadingPath("/dir/dir3", "/dir/dir3/link") returns true which it would
> not do if links have been resolved.
That's a good example and yes it would return false if we would change 
it to use canonical paths.

Which then makes me wonder - in the context of this specific 
untar/expand/unzip issue, should we probably be using a different custom 
very specific logic (which relies on canonical files and getParent()) 
instead of a call to isLeadingPath()? I don't have an answer though and 
I will have to sleep over this a bit to see if it has other implications 
and if it does indeed solve the issue at hand.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message