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 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.
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.
-Jaikiran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
