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

Alan Bateman Alan.Bateman at oracle.com
Tue Apr 2 09:53:35 UTC 2019

On 01/04/2019 14:38, Langer, Christoph wrote:
> :
> 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...
The issue with ZipFileAttributeView extending PosixFileAttributeView is 
that it change the attributes defined by the latter to optional, e.g. 
try readAttributes "zip:*" when enablePosixFileAttributes is enabled and 
disabled. I think it would be simpler, as least for the specification, 
to separate them.

> :
>> 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?
We'll need to do a bit of wordsmithing too. For example, the current 
draft has "It is possible to query a Path object .." when it should be 
saying "It is possible to query a file in a Zip file system ...".  This 
is all straight-forward, I think the main things now are to get 
agreement on the relationship between the different sets of attributes 
and the name of the permissions that the zip view supports.


More information about the core-libs-dev mailing list