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 m
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
co
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 mea
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 some
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% s
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 introduc
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 me.
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()) instead
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 m
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 se
n 28/06/18 7:17 PM, Stefan Bodewig wrote:
Hi all
while looking into https://bz.apache.org/bugzilla/show_bug.cgi?id=62502
I realized that I had a false expectation of what normalize would do in
a certain edge case.
If you feed into it a path with more &q
Hi all
while looking into https://bz.apache.org/bugzilla/show_bug.cgi?id=62502
I realized that I had a false expectation of what normalize would do in
a certain edge case.
If you feed into it a path with more "../" segments than can be
travelled up, like
FileUtils.normalize(
On Tue, 22 Feb 2005, Jeff Tulley <[EMAIL PROTECTED]> wrote:
> Hah, every time I think I'm going to unsubscribe from the ant dev
> list since I do not read it anymore, a thread catches my eye that
> inevitably has a NetWare question.
Which is why we are glad you don't unsubscribe.
If you ever do
--- Jeff Tulley <[EMAIL PROTECTED]> wrote:
> Hah, every time I think I'm going to unsubscribe
> from the ant dev list
> since I do not read it anymore, a thread catches my
> eye that inevitably
> has a NetWare question.
>
> I'm not sure, but I do not believe that Java on
> NetWare supports me
Hah, every time I think I'm going to unsubscribe from the ant dev list
since I do not read it anymore, a thread catches my eye that inevitably
has a NetWare question.
I'm not sure, but I do not believe that Java on NetWare supports me
jumping between servers by saying SERVER\VOLUME:PATH. I'll h
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Fri, 18 Feb 2005, Matt Benson
> <[EMAIL PROTECTED]> wrote:
>
> > OR it may be that we should detect these
> conditions as
> > NOT being absolute pathnames on DOS.
>
> As with most Windows/DOS features I'm pretty much on
> the fence.
>
> To me
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Fri, 18 Feb 2005, Matt Benson
> <[EMAIL PROTECTED]> wrote:
>
> > So we lie. :)
>
> Please fix the docs 8-)
In this case, I'd rather fix the implementation.
-Matt
>
> Stefan
>
>
---
Martijn Kruithof wrote:
Matt Benson wrote:
FileUtils.resolveFile claims to return absolute files;
however calling FileUtils.resolveFile(null, "\\") on
DOS returns the non-absolute File "\\". So we lie. :)
-Matt
No file on windows is allowed to have \ in the name, so \\ would not be a
valid file
On Fri, 18 Feb 2005, Matt Benson <[EMAIL PROTECTED]> wrote:
> So we lie. :)
Please fix the docs 8-)
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On Fri, 18 Feb 2005, Matt Benson <[EMAIL PROTECTED]> wrote:
> OR it may be that we should detect these conditions as
> NOT being absolute pathnames on DOS.
As with most Windows/DOS features I'm pretty much on the fence.
To me it sounds as if marking paths "C:foo" non-absolute and modify
resolve
--- Martijn Kruithof <[EMAIL PROTECTED]> wrote:
> Matt Benson wrote:
>
> >FileUtils.resolveFile claims to return absolute
> files;
> >however calling FileUtils.resolveFile(null, "\\")
> on
> >DOS returns the non-absolute File "\\". So we lie.
>
> >:)
> >
> >-Matt
> >
> >
>
> No file on wind
Matt Benson wrote:
FileUtils.resolveFile claims to return absolute files;
however calling FileUtils.resolveFile(null, "\\") on
DOS returns the non-absolute File "\\". So we lie.
:)
-Matt
No file on windows is allowed to have \ in the name, so \\ would not be a
valid file on dos at all (so not
Further file-related observations:
Project.resolveFile() methods claim to return
canonical files, but they actually defer to FileUtils
methods that claim to return absolute files.
FileUtils.resolveFile claims to return absolute files;
however calling FileUtils.resolveFile(null, "\\") on
DOS retur
This method will:
* Uppercase the drive letter if there is one.
* Remove redundant slashes after the drive spec.
* Resolve all ./, .\, ../ and ..\ sequences.
* DOS style paths that start with a drive letter
will have \ as the separator.
Other DOS considerations:
when a drive lett
25 matches
Mail list logo
