RFR 8213031: (zipfs) Add support for POSIX file permissions

[Langer, Christoph]

Hi Alan,

thanks for getting back on this.

> One thing that is puzzling is that
> ZipFileAttributeView/ZipFileAttributes extend
> PosixFileAttributeView/PosixFileAttributes. I don't think that will work
> because the "zip" view is supported by default whereas "posix" view
> needs the file system to be created with enablePosixFileAttributes=true.

Hm, when I was looking at it initially, I was also wondering if it would be cleaner either have a default ZipFileAttributeView/ZipFileAttributes implementation that doesn't extend Posix or an "Enhanced" ZipFileAttributeView/ZipFileAttributes that would extend Posix. But I saw in the implementation of ZipFileAttributeView::get that this is already the "gate" where the requester would get the ZipFileAttributeView implementation with the requested behavior set. So I was hoping that it'd be fine to handle the Posix extension this way. Do you really think that wouldn't work?

Alternatively, I could explore a different class hierarchy for ZipFileAttributeView/ZipFileAttributes...

> I saw your comment about naming the file permissions attribute
> "storedPermissions" in the zip view but if the zip and posix view are
> separated then I think it would be clearer to name it "permissions" in
> the zip view. If code is using Files.getAttribute then it will need the
> view name so they won't get mixed up.

Let me think about it...

> You asked about the fallback when defaultOwner/defaultGroup aren't set.
> If getOwner fails with an IOException then I think that exception should
> be propagated. The UOE case will fallback to the value of "user.name". I
> think the fallback for the group owner should be the file owner rather
> than "
> "<zipfs_default>". The default.policy file will need to be updated to
> grant jdk.zipfs RuntimePermission("accessUserInfo") so that you won't
> need to deal with security exceptions.

Sounds fine. I'll implement that.

> As regards next steps then I think we need to agree the spec changes, as
> in the the javadoc in module-info.java. Once we have the spec agreed
> then the CSR can be updated and finalized. The code review can be done
> in parallel of course. I think Lance is going to help review the changes.

Ok, I guess this eventually boils down to agree upon the right way of doing the "permissions" attribute or is there something more related to the spec?

Thanks
Christoph