RFR: JDK-8030048: (fs) Support UserDefinedFileAttributeView/extended attributes on OS X / HFS+
Alan Bateman
alanb at openjdk.java.net
Wed Jan 13 12:50:00 UTC 2021
On Sun, 10 Jan 2021 17:17:16 GMT, Sebastian Stenzel <github.com+1204330+overheadhunter at openjdk.org> wrote:
> This adds support for UserDefinedFileAttributeView on macOS 10.4 and newer.
>
> While the main audience for this will probably be macOS users, the relevant changes take place in (mostly existing) classes carrying BSD in their names as none of this is really macOS-specific.
>
> Code is mostly copied from the Linux implementation except for three differences:
> 1. max length for attribute names is 127 bytes
> 2. we know for sure that APFS and HFS+ support extended attributes, therefore we [simply return `true`](https://github.com/skymatic/jdk/blob/7a3619df12853bd3a44e4f49c98f35e15bceb652/src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java#L114-L118) from `supportsFileAttributeView(UserDefinedFileAttributeView.class)` for these two FS types, while for all other types support is determined experimentally in [`isExtendedAttributesEnabled(...)`](https://github.com/skymatic/jdk/blob/7a3619df12853bd3a44e4f49c98f35e15bceb652/src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java#L83-L100)
> 3. For the aforementioned check the new `UnixConstants.ENOATTR` is added, which [seems to be macOS and BSD-specific](https://mail-index.netbsd.org/tech-kern/2012/04/30/msg013090.html).
>
> As discussed in the mailing list, for ease of tracking changes it is not a goal of this patch to modernize the existing Linux implementation, nor to deduplicate anything.
Overall, this looks quite good and is easy to review.
I think the additions to BsdNativeDispatcher. will need a round or two of cleanup. They comments about XATTR_NOFOLLOW and other options documented in the man pages are a bit distracting. Also the style and excessive long lines aren't consistent with the existing code (and UnixNativeDispatcher).
One thing that we need to decide is whether the additional parameters (position, options) are exposed by BsdNativeDispatcher or not. I think I agree with your approach to have the signature match the methods in LinuxNativeDispatcher as that will make it easier to merge the two implementations later.
The comments that XATTR_NOFOLLOW is not applicable and other options not used is distracting and can be removed.
-------------
PR: https://git.openjdk.java.net/jdk/pull/2017
More information about the nio-dev
mailing list