On Mon, 13 Nov 2023 19:41:48 GMT, Brian Burkhalter wrote:
>> In the Windows implementation of java.io.File.getCanonicalPath, strip any
>> long path or UNC prefix before canonicalizing the remainder of the pathname.
>
> Brian Burkhalter has updated the pull request with a new target base due to
On Mon, 13 Nov 2023 19:49:17 GMT, Alan Bateman wrote:
> I assume you'll run the tests a number of times to make sure they are stable.
I always run tiers 1-3 before integrating, but will add also separate runs of
these tests with repeats.
-
PR Comment:
On Mon, 13 Nov 2023 19:41:48 GMT, Brian Burkhalter wrote:
>> In the Windows implementation of java.io.File.getCanonicalPath, strip any
>> long path or UNC prefix before canonicalizing the remainder of the pathname.
>
> Brian Burkhalter has updated the pull request with a new target base due to
> In the Windows implementation of java.io.File.getCanonicalPath, strip any
> long path or UNC prefix before canonicalizing the remainder of the pathname.
Brian Burkhalter has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the
On Sat, 11 Nov 2023 11:18:04 GMT, Alan Bateman wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8287843: Remove unused constant and method from WindowsPrefixes test
>
>
On Wed, 4 Oct 2023 20:35:25 GMT, Brian Burkhalter wrote:
>> In the Windows implementation of java.io.File.getCanonicalPath, strip any
>> long path or UNC prefix before canonicalizing the remainder of the pathname.
>
> Brian Burkhalter has updated the pull request incrementally with one
>
On Mon, 16 Oct 2023 16:31:04 GMT, Brian Burkhalter wrote:
> The CSR was created.
Thanks. I changed the "Compatibility Risk" to medium and expanded its
description to more clearly explain the compatibility risk to fix this long
standing issue.
-
PR Comment:
On Wed, 4 Oct 2023 20:35:25 GMT, Brian Burkhalter wrote:
>> In the Windows implementation of java.io.File.getCanonicalPath, strip any
>> long path or UNC prefix before canonicalizing the remainder of the pathname.
>
> Brian Burkhalter has updated the pull request incrementally with one
>
> In the Windows implementation of java.io.File.getCanonicalPath, strip any
> long path or UNC prefix before canonicalizing the remainder of the pathname.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8287843: Remove unused
On Mon, 2 Oct 2023 23:12:24 GMT, Brian Burkhalter wrote:
> remove stripLongOrUNCPrefix() except in normalize()
I haven't had time to look at the test changes yet but the I think the code
changes look okay so I think go ahead and create the CSR as this behavior
change will need to be tracked.
> In the Windows implementation of java.io.File.getCanonicalPath, strip any
> long path or UNC prefix before canonicalizing the remainder of the pathname.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8287843: remove
On Thu, 21 Sep 2023 00:46:45 GMT, Brian Burkhalter wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8287843: Move prefix stripping to separate method; add to isAbsolute
>
> Support for `isAbsolute` was added.
> In the Windows implementation of java.io.File.getCanonicalPath, strip any
> long path or UNC prefix before canonicalizing the remainder of the pathname.
Brian Burkhalter has updated the pull request incrementally with three
additional commits since the last revision:
- 8287843: Strip prefix
On Thu, 21 Sep 2023 00:46:45 GMT, Brian Burkhalter wrote:
> Support for `isAbsolute` was added.
Okay, this looks better but I'm still concerned about other potential
inconsistencies. Can you try out getParent with different input to see if any
issues come up related to the prefix length.
On Wed, 20 Sep 2023 23:48:13 GMT, Brian Burkhalter wrote:
>> In the Windows implementation of java.io.File.getCanonicalPath, strip any
>> long path or UNC prefix before canonicalizing the remainder of the pathname.
>
> Brian Burkhalter has updated the pull request incrementally with one
>
> In the Windows implementation of java.io.File.getCanonicalPath, strip any
> long path or UNC prefix before canonicalizing the remainder of the pathname.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8287843: Move prefix
On Wed, 20 Sep 2023 18:10:17 GMT, Brian Burkhalter wrote:
>> In the Windows implementation of java.io.File.getCanonicalPath, strip any
>> long path or UNC prefix before canonicalizing the remainder of the pathname.
>
> Brian Burkhalter has updated the pull request incrementally with one
>
On Wed, 20 Sep 2023 18:47:33 GMT, Brian Burkhalter wrote:
> > File::isAbsolute, it looks like it will return true for input like
> > `\\\?\\foo` but it will be treated by toAbsolutePath as a relative path.
>
> Right on:
Ideally the prefix would be removed at the front door, meaning when
On Wed, 20 Sep 2023 18:42:31 GMT, Alan Bateman wrote:
> File::isAbsolute, it looks like it will return true for input like
> `\\\?\\foo` but it will be treated by toAbsolutePath as a relative path.
Right on:
jshell> File f = new File("\\\?\\foo")
f ==> \?\foo
jshell> f.isAbsolute()
$2 ==>
On Wed, 20 Sep 2023 18:10:17 GMT, Brian Burkhalter wrote:
>> In the Windows implementation of java.io.File.getCanonicalPath, strip any
>> long path or UNC prefix before canonicalizing the remainder of the pathname.
>
> Brian Burkhalter has updated the pull request incrementally with one
>
On Wed, 20 Sep 2023 07:26:02 GMT, Alan Bateman wrote:
> the one-arg WinNTFileSystem.resolve may be the right place to check for the
> prefix
So changed in a8726fbb8a070388f2b9756ee88c746b12c18397 which also adds a couple
of test cases. Perhaps some cases should be added to the
> In the Windows implementation of java.io.File.getCanonicalPath, strip any
> long path or UNC prefix before canonicalizing the remainder of the pathname.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8287843: Move \\?\ prefix
On Wed, 20 Sep 2023 02:14:48 GMT, Brian Burkhalter wrote:
> It could be that if after stripping the `\\\?\` prefix the result is relative
> or drive-relative, then it should first be resolved in the same way before
> proceeding.
Right, which is why the one-arg WinNTFileSystem.resolve may be
On Mon, 11 Sep 2023 16:24:32 GMT, Brian Burkhalter wrote:
> These also fail with "Bad pathname" with the master but give the erroneous
> results `C:\\\foo` and `C:`, respectively, with the patch. This
> needs to be fixed.
The problem here might be that `File.getCanonicalPath` resolves the
On Sat, 9 Sep 2023 08:32:44 GMT, Alan Bateman wrote:
> For `\\\?\`, the normalization will drop the trailing slash so the path
> string is actually `\\\?`. I think that case is okay.
This results in "Bad pathname" with both the master and the change.
> For input such as `\\\?\\foo` and
On Fri, 8 Sep 2023 01:07:17 GMT, Brian Burkhalter wrote:
>> In the Windows implementation of java.io.File.getCanonicalPath, strip any
>> long path or UNC prefix before canonicalizing the remainder of the pathname.
>
> Brian Burkhalter has updated the pull request incrementally with one
>
On Fri, 8 Sep 2023 01:07:17 GMT, Brian Burkhalter wrote:
>> In the Windows implementation of java.io.File.getCanonicalPath, strip any
>> long path or UNC prefix before canonicalizing the remainder of the pathname.
>
> Brian Burkhalter has updated the pull request incrementally with one
>
On Fri, 8 Sep 2023 10:00:42 GMT, Alan Bateman wrote:
> The two cases that I'm wondering about are `\\\?\` and `\\\?\\UNC`.
Both of these cases throw an IOE with message "Bad pathname" for
`getCanonicalPath()` and `getParentFile().getCanonicalPath()` with both the
mainline and with this
On Fri, 8 Sep 2023 10:00:42 GMT, Alan Bateman wrote:
> I'm trying to see how this case fails in the badPaths list.
I'll investigate the other topics you raise, but I should point out that the
results of this test are the same as for the mainline except for the last two
good paths
On Fri, 8 Sep 2023 01:07:17 GMT, Brian Burkhalter wrote:
>> In the Windows implementation of java.io.File.getCanonicalPath, strip any
>> long path or UNC prefix before canonicalizing the remainder of the pathname.
>
> Brian Burkhalter has updated the pull request incrementally with one
>
> In the Windows implementation of java.io.File.getCanonicalPath, strip any
> long path or UNC prefix before canonicalizing the remainder of the pathname.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8287843: Handle
On Thu, 7 Sep 2023 08:33:39 GMT, Alan Bateman wrote:
> Would it be possible to summarise how this behaves when File just represents
> a prefix?
Baseline:
jshell> File f = new File("\\\?\")
f ==> \?
jshell> f.getCanonicalPath()
| Exception java.io.IOException: Bad pathname
|at
On Wed, 6 Sep 2023 21:38:39 GMT, Brian Burkhalter wrote:
> In the Windows implementation of java.io.File.getCanonicalPath, strip any
> long path or UNC prefix before canonicalizing the remainder of the pathname.
Would it be possible to summarise how this behaves when File just presents this
On Wed, 6 Sep 2023 21:40:14 GMT, Brian Burkhalter wrote:
> No `File` methods aside from `getCanonicalPath` are affected.
That is to say, other than `GetCanonicalFile`, of course.
-
PR Comment: https://git.openjdk.org/jdk/pull/15603#issuecomment-1709178997
In the Windows implementation of java.io.File.getCanonicalPath, strip any long
path or UNC prefix before canonicalizing the remainder of the pathname.
-
Commit messages:
- 8287843: File::getCanonicalFile doesn't work for \?\C:\ style paths DOS
device paths
Changes:
On Wed, 6 Sep 2023 21:38:39 GMT, Brian Burkhalter wrote:
> In the Windows implementation of java.io.File.getCanonicalPath, strip any
> long path or UNC prefix before canonicalizing the remainder of the pathname.
No `File` methods aside from `getCanonicalPath` are affected.
The existing
36 matches
Mail list logo