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

Alan Bateman Alan.Bateman at oracle.com
Mon Jan 7 19:09:44 UTC 2019


On 07/01/2019 11:13, Langer, Christoph wrote:
>
> Hi,
>
> I’ve amended the jdk.zipfs module documentation in 
> src/jdk.zipfs/share/classes/module-info.java to document the new 
> behavior (e.g. support of PosixFileAttributeView) as requested by 
> Alan. I’ve also updated the CSR.
>
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.4/ 
> <http://cr.openjdk.java.net/~clanger/webrevs/8213031.4/>
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 
> <https://bugs.openjdk.java.net/browse/JDK-8213082>
>
>
I think this is on the right path now. I'll start with the javadoc as 
that will take a few iterations and you'll need to get that agreed 
before finalizing the CSR.

The proposed update starts out "Path objects residing in a zip file 
system ..." isn't quite right. I think you want start with something 
like "File systems created by the zip file system provider support the 
POSIX file attributes defined by the {@link PosixFileAttributeView}".

I think the main issue that will need to be worked out is how the bulk 
read PosixFileAttributeView::readAttributes behaves when the zip entry 
doesn't have the external file attributes. UOE isn't right because UOE 
should be thrown or not thrown based on concrete/implementation type. 
One option is to throw IOE, another is to have it return a 
PosixFileAttributes that contains an empty permission set. The latter 
has the advantage that  you can pass the object to anything that excepts 
a BasicFileAttributes. Having set/getOwner throw UOE is okay. Once we 
have agreement on how the bulk read behaves then it should be easy to 
agree the javadoc change.

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20190107/52c1e0f2/attachment.htm>


More information about the security-dev mailing list