Skip to content

Conversation

Copy link
Contributor

Copilot AI commented Oct 26, 2025

WSL2 mapped network drives throw IOException when querying file ownership via Files.getAttribute(), causing FileAttributes constructor to fail. The filesystem reports it supports the owner view but then fails when accessed.

Changes

  • Modified getPrincipalName() to catch IOException and return null instead of propagating
  • Added @Nullable annotation to document return contract
  • Added test verifying graceful handling when ownership info unavailable

The existing code already handles null ownership values correctly - all call sites assign to nullable fields that support unknown ownership state.

@Nullable
private static String getPrincipalName(Path path, String attribute) {
    try {
        Object owner = Files.getAttribute(path, attribute, LinkOption.NOFOLLOW_LINKS);
        return ((Principal) owner).getName();
    } catch (IOException e) {
        // WSL2 mapped network drives and other filesystems may not provide ownership
        return null;
    }
}

Fixes issue where Maven JAR/WAR plugins fail on WSL2 network-mounted paths.

Original prompt

This section details on the original issue you should resolve

<issue_title>WLS file processing will fail in FileAttributes</issue_title>
<issue_description>Windows Linux Subsystem (WLS) mapped network drive files don't provide file ownership data. FileAttributes class constructor fails when attempting to fetch this information.
Looks like the problematic code has been rewritten in #33 .

This has side effect to Maven JAR Plugin (MJAR-273) and Maven WAR Plugin</issue_description>

Comments on the Issue (you are @copilot in this section)

@plamentotev @forsmpa thanks for reporting. I'll take a look at it. Just to confirm - the change you mentioned as the root cause is not yet released. So I guess you get this error only with master and not with the latest release, right? @michael-o This may also be incomplete support in Java, not our fault. At best someone could come up with an isolated usecase and report it to Rory O'Donnell and/or the nio-dev mailing list. @plamentotev I've read the MJAR-273 description. So the root cause seems to be that Java throws exception when a file owner is requested.
  1. It appears that older versions of the JAR plugin are working. I didn't have the time to check why older version are not throwing exceptions. Maybe they are using different APIs.
  2. Maybe there is some issue with Java as well. @michael-o how we can report it? It is easy to reproduce. You just need a WSL 2 (Windows Linux Subsystem 2) path mapped as network drive (haven't tried with other mapped network drives, maybe it is not WSL2 related). Then if you execute from Windows (and not Linux) Files.getFileAttributeView(Paths.get("pom.xml"), java.nio.file.attribute.FileOwnerAttributeView.class, LinkOption.NOFOLLOW_LINKS).getOwner() will reproduce the issue. Of course pom.xml should exist and it should be located on the mapped drive. My understanding is that if FileOwnerAttributeView is not supported then Files.getFileAttributeView should return null. But non-null is returned that latter just throws IO exception.</comment_new>
    <comment_new>@michael-o
    Rory told me report the issue here. As soon it is publically available, drop him an email with the reference to Maven and he will take care (pass on to others).</comment_new>
    <comment_new>@plamentotev
    I've reported it. Lets see what happens. But it could also be WSL limitation. In any case -attributes such as ownership may not be available on all file systems. What we should do in such case? I think we support unknown values for file attributes so I think we should return those values instead of throwing exception</comment_new>
    <comment_new>@michael-o
    Please provide the internal bug id. I will contact Rory.</comment_new>
    <comment_new>@plamentotev

Please provide the internal bug id. I will contact Rory.

9068518</comment_new>
<comment_new>@michael-o
Mailed Rory, let's what happens.</comment_new>
<comment_new>@michael-o
@forsmpa This has already been reported with Oracle. I will try to reach out next week.</comment_new>
<comment_new>@plamentotev
btw I've experimented a bit with WSL2 file system mapped as network drive. Looks like even the dir command does not show the ownership information. Python's os.stat also return null values for ownership. Maybe it is limitation of WSL 2?</comment_new>
<comment_new>@michael-o
https://bugs.openjdk.java.net/browse/JDK-8259617</comment_new>


💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

Copilot AI changed the title [WIP] Fix WLS file processing failure in FileAttributes Handle IOException when retrieving file ownership on WSL2 network drives Oct 26, 2025
Copilot AI requested a review from slachiewicz October 26, 2025 07:34
Copilot finished work on behalf of slachiewicz October 26, 2025 07:34
@slachiewicz slachiewicz marked this pull request as ready for review October 26, 2025 11:12
@slachiewicz slachiewicz merged commit aef5f5b into master Oct 26, 2025
19 checks passed
@slachiewicz slachiewicz deleted the copilot/fix-wls-file-attributes-error branch October 26, 2025 12:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

WLS file processing will fail in FileAttributes

2 participants