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 java.io.File#getCanonicalFile() 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
> java.io.File#getCanonicalFile() 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.
> 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.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
