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