ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: FileUtils.normalize/isLeadingPath have bitten me
Date Thu, 28 Jun 2018 15:07:52 GMT
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

     link -> /dir/dir2

isLeadingPath("/dir/dir3", "/dir/dir3/link") returns true which it would
not do if links have been resolved.

> Do you think this has merits? Or is the expectation of the
> isLeadingPath API solely based on the names of that passed files
> rather than their actual resolved location on the filesystem?

Yes, I think so.

> I haven't yet tried it out myself to have a more clearer understanding
> of how it will end up behaving in the context that we use this API.

It is used in SymbolicLinkUtils in a way that might break if symbolic
links are resolved.


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

View raw message