FULL PRODUCT VERSION :
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Red Hat Enterprise Linux 6.3
Red Hat Enterprise Linux 7.1
Arch Linux (latest)

A DESCRIPTION OF THE PROBLEM :
On Linux assume there is a directory "/tmp/foo" which has mode 2755 (drwxr-sr-x). Test system is a RHEL 6.3 in this case with OpenJDK 7 but I observed the same with OpenJDK 8 on Arch Linux as well.

The Java code included in this bug report shall change the permissions in order to give the group write access to the directory.

The result of this operation is a directory with mode 0775 which means that the "g+w" call succeeded but the 'setgid' bit got lost. The same happens with the 'setuid' and the sticky bit. I know that NIO2 does not claim to support access to special bits (see link below) but why is it then removing and hence effectively "touching" them?

http://docs.oracle.com/javase/8/docs/api/java/nio/file/attribute/PosixFileAttributeView.html

I think this behavior is sort of inconsistent. The mechanism should either provide full support for special bits or leave them untouched entirely.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Required:
Linux file system supporting POSIX permissions with special bits (setuid/setgid/sticky).

Create a directory "/tmp/foo" and set its mode to 2755 (drwxr-sr-x):

mkdir -p /tmp/foo && chmod 2755 /tmp/foo

Then launch the example Java code included in this bug report (see below).

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
"/tmp/foo" has mode 2775 (drwxrwsr-x).
ACTUAL -
"/tmp/foo" has mode 0775 (drwxrwxr-x).

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
try {
    Path path = Paths.get("/tmp", "foo");

    Set<PosixFilePermission> perms = Files.getPosixFilePermissions(path);
    perms.add(PosixFilePermission.GROUP_WRITE);

    Files.setPosixFilePermissions(path, perms);
}
catch (IOException e) {
    e.printStackTrace();
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
A JNA implementation of the "chmod" syscall works around this problem. Also a process fork of the OS "chmod" binary works around it. However I do not consider both as a real workaround.