FS#58057 - [jdk9-openjdk] user_xattr support detection broken on ext4

Attached to Project: Arch Linux
Opened by Phillip Schichtel (pschichtel) - Sunday, 01 April 2018, 01:33 GMT
Last edited by Jelle van der Waa (jelly) - Sunday, 28 April 2019, 10:42 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Guillaume ALAUX (galaux)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Java supports user_xattr since version 7 in the form of a file attribute view: https://docs.oracle.com/javase/7/docs/api/java/nio/file/attribute/UserDefinedFileAttributeView.html
Support for this view can be tested using Files.getFileStore(Paths.get("/path")).supportsFileAttributeView(UserDefinedFileAttributeView.class).
This function will internally extract the mount options from /proc/mounts and check for the user_xattr option. On recent kernels the user_xattr option is the default and there now only exists nouser_xattr. The implementation in LinuxFileStore also special cases ext3 and ext4 explicitly as "does not support extended attributes by default", so the function directly terminates with "no support" instead of going on with probing the file system for support by calling fgetxattr. I guess this implementation is from a time when this was actually true, though I don't understand why the special case was added when the fgetxattr call would have yielded the exact same result.

The proper solution would probably be to remove the special case from LinuxFileStore.supportsFileAttributeView, but there is an alternative workaround:
Before any actual feature detection UnixFileStore.checkIfFeaturePresent will try to load the ${java.home}/lib/fstypes.properties file. This file is a standard properties file with filesystem types as the key and space-separated mount-options/feature-flags.

So the solution would be to add this file to all affected packages with the content "ext4=user_xattr"

Additional info:
* This affects any version from 1.7 through 10.
* attached is my /usr/lib/jvm/java-8-openjdk/jre/lib/fstypes.properties as described above.
* I will report this upstream with a request to remove the special case from the code base. If that request gets accepted, this could possibly be ported to all versions except probably 1.7 as it's EOL.
* I have tested the fstypes.properties approach locally with several different JDKs >=8 in an application and it works without problems.


Steps to reproduce:
1. Call Files.getFileStore(Paths.get("/path")).supportsFileAttributeView(UserDefinedFileAttributeView.class) (e.g. in a scala shell) with a path on an ext4 file system with user_xattr enabled.
2. Returns false even through xattr is supported.
This task depends upon

Closed by  Jelle van der Waa (jelly)
Sunday, 28 April 2019, 10:42 GMT
Reason for closing:  Deferred
Additional comments about closing:  Removed from repos
Comment by Phillip Schichtel (pschichtel) - Sunday, 01 April 2018, 02:07 GMT
Reported upstream. Review ID: 9053193
Comment by Phillip Schichtel (pschichtel) - Sunday, 01 April 2018, 03:28 GMT
I quickly build a small patch (attached), but I haven't tested it yet.
Comment by (Det) - Sunday, 01 April 2018, 18:38 GMT Comment by Phillip Schichtel (pschichtel) - Monday, 02 April 2018, 18:07 GMT
Yep, that's exactly the same problem.
Comment by Phillip Schichtel (pschichtel) - Friday, 20 April 2018, 10:35 GMT
Upstream resolved this for java11, would backportings be viable?

Loading...