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

[Volker Simonis]

Hi Alan,

thaks for looking at the javadoc/CSR.

On Mon, Jan 7, 2019 at 8:10 PM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> 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/
>
> CSR: 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.

We considered this, but it is problematic because it is perfectly
valid to have a file with external file attributes where none of the
Posix attributes is actually set (i.e. an empty set of Posix files
attributes). This wouldn't be distinguishable from the case where a
file has no external file attributes. So it seems we have to resort to
throwing an IOE?

> 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.