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
