Hi Stefan,
I did some testing manually for this new method, with both symlinks and
non-symlinks with both the string check version and the getParent()
version. In both of those, I couldn't get it to break in any odd ways
(which is a good thing). It also means that my theory that the string
comparison may not always be a best idea is just theoretical. However, I
just feel a bit more comfortable seeing the getParent() version since
that then removes any kind of file separator or odd backslash/frontslash
permutations that we may not have thought of and instead leaves it to
the JRE implementation to deal with it. Again, this is me being a bit
paranoid than any real demoable issue with the string comparison code.
So thank you for using the getParent() call in this implementation.
At this point, I think these commits address the issue that we sought
out to fix. So unless someone else sees any issues, I think we can go
ahead and do the release that you had planned for.
-Jaikiran
On 03/07/18 1:16 PM, Stefan Bodewig wrote:
On 2018-07-02, Stefan Bodewig wrote:
On 2018-07-02, Jaikiran Pai wrote:
I just checked the commits related to this and it looks mostly
correct. However, I am still not 100% sure we have covered it all with
this new method that was introduced[1] and used in the unzip
part. What I mean is, the API expectations are right. However the
implementation _might_ need a bit of rethink since it still relies on
path string comparison (checks like endsWith) instead of a getParent()
check.
I mostly kept the string comparison for performance reasons, but maybe
that point is moot and performance should not be a concern
here. Rewriting it to use getParent is no problem at all.
Done
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
