Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WLS file processing will fail in FileAttributes #36

Open
forsmpa opened this issue Dec 31, 2020 · 12 comments
Open

WLS file processing will fail in FileAttributes #36

forsmpa opened this issue Dec 31, 2020 · 12 comments

Comments

@forsmpa
Copy link

forsmpa commented Dec 31, 2020

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

@plamentotev
Copy link
Member

@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
Copy link
Member

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
Copy link
Member

plamentotev commented Jan 4, 2021

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.

@michael-o
Copy link
Member

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).

@plamentotev
Copy link
Member

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

@michael-o
Copy link
Member

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

@plamentotev
Copy link
Member

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

9068518

@michael-o
Copy link
Member

Mailed Rory, let's what happens.

@forsmpa
Copy link
Author

forsmpa commented Jan 27, 2021

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.

I finally had time to look at this even more. The second scenario seams to be the case. Some output from the FileAttributes constructor (current HEAD + debug prints) that was my case:
File : U:\home\username\projects\PROJECT\Maven_Module\target\Maven_Module-1.0.0-SNAPSHOT\WEB-INF\web.xml
Path : U:\home\username\projects\PROJECT\Maven_Module\target\Maven_Module-1.0.0-SNAPSHOT\WEB-INF\web.xml
FileSystem : sun.nio.fs.WindowsFileSystem@5fbb797f
Views : [owner, dos, acl, basic, user]
Names : basic:*
Files attributes : {
lastAccessTime=2021-01-26T12:37:41.11Z,
lastModifiedTime=2021-01-26T12:37:41.12Z,
size=2085,
creationTime=2021-01-26T12:37:41.11Z,
isSymbolicLink=false,
isRegularFile=true,
fileKey=null,
isOther=false,
isDirectory=false
}

In my current findings and case this has an impact on the following plugins.

  • maven-jar-plugin
    -- which is used by asciidoctor-maven-plugin
  • maven-war-plugin
  • maven-ear-plugin
  • maven-assembly-plugin

Yes surrounding Files.readAttributes(path, "owner:*", LinkOption.NOFOLLOW_LINKS) call in constructor with try-catch will "solve" the problem, but the underlying issue seams to be on JDK level. I guess the current ticket will only apply to Oracle JDK so as we are using AdoptOpenJDK 11 HotSpot we need a ticket for them for a fix for this.

@michael-o
Copy link
Member

@forsmpa This has already been reported with Oracle. I will try to reach out next week.

@plamentotev
Copy link
Member

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?

@michael-o
Copy link
Member

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

No branches or pull requests

3 participants