RFR: 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) [v4]

[Alan Bateman]

On Tue, 2 Nov 2021 00:28:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `sun.nio.fs.WindowsUserDefinedFileAttributeView.join(WindowsPath,String)` to handle file names which exceed the limit.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge
>  - 8273922: Change absolute path check to check for name count and root presence
>  - 8273922: Make join() reject absolute path in 1nth in 'name' parameter
>  - 8273922: Add bug ID to @bug in test
>  - 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win)

Thanks for the update, I think we are close to being done.

src/java.base/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java line 61:

> 59:         WindowsPath namePath = WindowsPath.parse(wfs, name);
> 60:         if (namePath.getRoot() != null)
> 61:             throw new IllegalArgumentException("'name' is not relative");

The exception message should "has a root component" because a name such as "C:foo" is relative.

src/java.base/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java line 63:

> 61:             throw new IllegalArgumentException("'name' is not relative");
> 62:         if (namePath.getNameCount() != 1)
> 63:             throw new IllegalArgumentException("'name' has more than one element");

Alternatively, just check if getParent() returns null.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5594