git.net

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

Re: FileUtils.normalize/isLeadingPath have bitten me


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