Hi Alan, first of all, thank you for your input on this.
> 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. OK, I can see the point that in a PosixFileAttributeView as it is, there's no place for optionality/null values. However, with this approach the benefits would be that Files::get/setPosixPermissions would work and that's why I think we should pursue this. The challenge will be to find reasonable defaults. > 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. For this approach, there are 2 things I dislike. The first is that I don't think we should export named packages from module jdk.zipfs that people would develop Java code against while not being in the Java API. And secondly, this way would not support using Files::set/getPosixPermissions since the specification/implementation of that utility method explicitly refers to PosixFileAttributeView. I can imagine something like this: Zipfs by default implements an own view that offers dynamic, not type safe access to "zip:permissions" and we'll document this. If a user of zipfs wants to see full PosixFileAttributeView support with default values, then we should allow for a creation attribute for the zipfs that can control this. Maybe we can even allow specifying default values for user, group and permissions via zipfs attributes. I'll work to develop the patch into this direction unless you tell me that this idea is bogus (if so, then I hope it be soon 😊) Thanks Christoph
