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

[Alan Bateman]

On 12/01/2019 13:02, Langer, Christoph wrote:
> Hi Alan,
>
> as I did not hear back from you I continued to work on the POSIX file permission support for zipfs and specified/implemented the value of 'null' for zip entries with no permission information associated (vs. UnsupportedOperationException).
>
> I updated the CSR: https://bugs.openjdk.java.net/browse/JDK-8213082
>
I don't think zipfs can support PosixFileAttributeView in this way 
because zip entries can only support a subset of the attributes that the 
view defines. Retrofitting optionality to allow it be used in a degraded 
manner would be an incompatible change and of course creates usability 
issues. The owner, group and permissions methods defined by 
PosixFileAttributes cannot return null or throw exceptions.

I think the approach to explore are:

1. zipfs supports PosixFileAttributeView without subsetting. If 
readAttribute(file, BasicFileAttributes.class) succeeds then 
readAttribute(file, PosixFileAttributes.class) should also succeed, even 
if there aren't permissions encoded in the zip entry's external file 
attributes. It would mean that owner and group return default values, 
and permissions may return a default value. It does mean you can't 
distinguish the default value from "no permissions" but there is 
precedence for that, e.g. mount a FAT32 file system on Linux or Unix 
systems and `stat` a file to have the stat structure populated with 
default uid, gid and mode bits.

2. zipfs defines a new FileAttributeView that defines read and write 
access to permissions stored in a zip entry's external file attribute. 
As it's a new view then it can define the behavior for the case that the 
zip entry doesn't have permissions. Furthermore it does not need to 
extend BasicFileAttributeView so doesn't need to be concerned with bulk 
access, nor concerned with group/owner. As you know, the attributes API 
allows for both type safe and dynamic access so you have a choice as to 
whether to support both or just dynamic access. With the first then 
jdk.zipfs would export a package with a public interface that defines 
the view. If someone wants type safe access to the permissions attribute 
then you need to import the class. The alternative is to not export any 
packages but just define the view in the module-info. The view its name 
and define the name/type of the permissions attribute, it will also 
define how it behaves when the external attributes aren't populated. In 
usage terms it means reading the permissions will be something like 
Files.readAttribute(file, "zip:permissions") and casting the value to 
Set<PosixFilePermission> - not pretty but it avoids depending on a 
JDK-specific API.

I think it would be good to explore these options and maybe we can 
converge on an approach in the coming weeks.

-Alan