8030048: (fs) Support UserDefinedFileAttributeView/extended attributes on OS X / HFS+

[Sebastian Stenzel]

> On 10. Jan 2021, at 15:58, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 08/01/2021 13:45, JaniruTEC wrote:
>> 
>> My employer wrote a proof of concept that heavily utilizes the existing linux code to create a BSD implementation, which can be found here: https://urldefense.com/v3/__https://github.com/skymatic/jdk/tree/feature/macos-xattr__;!!GqivPVa7Brio!L6gpaYGumU5fAqlD9-_hNfdJmKqmm7A-bNPr8wRolGyrMcK0m2CIYGz9g3TTKra8sg$ 
>> We have a few questions now:
>> - Since BSD and Linux share so much code, we believe deduplication could be a reasonable matter. Should this be part of this PR or a second one? Is deduplication even a matter you wish us to pursue?
>> - The Linux implementation doesn't utilize newer java features. Which is the latest java version the BSD Implementation should utilize features of? Should the Linux version be updated as well? How does backporting affect this decision?
>> - At what point in time should the PR be created? Is communication over Mail or over the PR preferred?
> If this is mostly a clone of the implementation from src/java.base/linux then it may make sense to move it to src/java.base/unix and then have it conditionally compiled in on the platforms that support it. We haven't needed to do anything significant on that attribute view is a long time so modernizing make sense too. My personal preference is to have the changes be as easy to review as possible. If we can't see the diffs in the files change and/or webrev view then it will awkward to review. So if you can split into 2 or 3 patches then it might be easier. If the patches are small then starting with a PR is okay. If the changes are large then it's better to discuss and get agreement on the mailing lists before trying to get detailed reviews.
> 
> I don't think I understand your question about the BSD port as it is maintained in a downstream project. We just maintain the macOS port here.
> 
> -Alan


I agree that in order to easily follow what has changed, we should do two separate patches:

1. add macOS support and accept the fact that this is 90% duplicated code from Linux
2. deduplicate and modernize


Regarding the BSD confusion: MacOSXFileSystemProvider extends BsdFileSystemProvider. We have four system calls (fgetxattr, fsetxattr, fremovexattr, flistxattr), all of them not being macOS-specific, but rather inherited from the BSD-based XNU kernel. If you look up the man pages for any of them on macOS, you'll get the BSD man page.

That is why we thought it would be best to put the added code to the most generic place possible, which is (currently) the BsdFileSystemProvider. After dedup it will probably be UnixFileSystemProvider, however some distinctions will be required.


Tests look good btw:

   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/jdk/java/nio/file                         61    61     0     0  


Should we create a PR to proceed with the review? If so, what would be an appropriate name (like should it contain the bug id)?

Cheers,
Sebastian