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
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
|
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
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
Comment by
Phillip Schichtel (pschichtel) -
Sunday, 01 April 2018, 03:28 GMT
Comment by (Det) - Sunday, 01
April 2018, 18:38 GMT
Comment by
Phillip Schichtel (pschichtel) -
Monday, 02 April 2018, 18:07 GMT
Comment by
Phillip Schichtel (pschichtel) -
Friday, 20 April 2018, 10:35 GMT
Reported upstream. Review ID: 9053193
I quickly build a small patch (attached), but I haven't tested it
yet.
Bug from 2013?:
https://bugs.openjdk.java.net/browse/JDK-8009632
Yep, that's exactly the same problem.
Upstream resolved this for java11, would backportings be viable?