Please review this PR to fix to a regression in ZipFileSystem, introduced by JDK-8322565 in PR #17170.
When `Files.setPosixFilePermissions` is called on an existing MSDOS entry, then `Entry.posixPerms` field will be -1 (all 1s in binary). The logic introduced by JDK-8322565 did not account for this and incorrectly sets the leading seven bits to all ones instead of all zeros. The fix is to introduce a branch for `Entry.posixPerms` being -1 and deal with that case separately. The PR adds a test case to `TestPosix` which reproduces the regression. While visiting this test, I also fixed an incorrect spelling of `setPosixFilePermissions` (also introduced by #17170). ------------- Commit messages: - If the entry currently has no permissions set, don't try to merge permission bits with existing -1 bits Changes: https://git.openjdk.org/jdk/pull/17556/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17556&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324635 Stats: 31 lines in 2 files changed: 29 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17556.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17556/head:pull/17556 PR: https://git.openjdk.org/jdk/pull/17556
