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
