git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FileUtils.normalize/isLeadingPath have bitten me



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-unsubscribe@xxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxx