On 2018-07-03, Jaikiran Pai wrote:
> 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
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
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
Hi Nicolas
many thanks for lending an extra pair of eyes. I'll add a few more
tests.
Stefan
On 2018-07-01, Nicolas Lalevée wrote:
> At my first read of the code I wondered if paths ending with slash are
> properly handled in every case. After more careful reading, it is seems ok.
> Maybe
On 2018-07-02, Jaikiran Pai wrote:
> Sorry that I couldn't get to this earlier. My plan to spend more time
> on this during the weekend didn't work out.
It's been a weekend :-)
No worries.
> I just checked the commits related to this and it looks mostly
> correct. However, I am still not 100%
Hi Stefan,
Sorry that I couldn't get to this earlier. My plan to spend more time on
this during the weekend didn't work out.
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
At my first read of the code I wondered if paths ending with slash are properly
handled in every case. After more careful reading, it is seems ok. Maybe some
unit tests about it would be nice, just to be sure.
Then, about tackling the bug, I am on the same page as you both. It looks good
to
On 2018-06-28, Stefan Bodewig wrote:
> On 2018-06-28, Jaikiran Pai wrote:
>> 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())
On 2018-06-28, Jaikiran Pai wrote:
> On 28/06/18 8:37 PM, Stefan Bodewig wrote:
>> /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
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
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
I don't have enough background on the expectations of the normalize
method, so can't really say how it should behave. Plus, it gets used in
relatively larger number of places as compared to isLeadingPath, so not
too sure how it might impact other places if we do change its existing
semantics.
12 matches
Mail list logo
