Hi Alan,
I've got a new iteration for the zipfs POSIX support and addressed your
concerns: http://cr.openjdk.java.net/~clanger/webrevs/8213031.9/
The new change bases on the proposal for JDK-8222276, which I created to factor
out changes unrelated to POSIX to facilitate easier reviewing of this patch.
In details:
> 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.
I separated ZipFileAttributeView and ZipFileAttributeViewPosix. I also created
a class EntryPosix inside ZipFileSystem.java that extends the default Entry
class and additionally implements PosixFileAttributes. It is used, depending on
whether Posix support is turned on or not. I unfortunately had to touch all the
places where new Entry objects are created and either create a Posix entry or a
default Entry.
> 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.
It's always "permissions" now. In case, it is a default ZipFileSystem, the
attribute is optional. If supportPosix is true, it'll always be available using
default values.
> 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.
Ok, done 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.
I have updated module-info a little bit to reflect the latest changes. Is it
now time to focus on the CSR?
Thanks
Christoph
