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.

-Alan


More information about the nio-dev mailing list