Files.createSymbolicLink() takes an array of FileAttribute<?> as an argument; does it make sense on any OS?

Question

The prototype of Files.createSymbolicLink() is:

static Path createSymbolicLink(Path link, Path target,
    FileAttribute<?>... attrs)

Well... Why?

A symlink is nothing else than an inode whose content is a string pointing to... Well, whatever. The target can even not be valid at all.

Out of curiosity, I tried this (yes, it runs as root, but this is on purpose here):

root@alustriel:/tmp# cat Test.java
import java.io.IOException;
import java.nio.file.*;
import java.nio.file.attribute.*;

public final class Test {
    public static void main(final String... args) throws IOException {
        final UserPrincipalLookupService lookupService =
                FileSystems.getDefault().getUserPrincipalLookupService();

        final UserPrincipal user = lookupService.lookupPrincipalByName("fge");

        final FileAttribute<UserPrincipal> attr =
                new FileAttribute<UserPrincipal>() {
            @Override
            public String name() {
                return "owner:owner";
            }

            @Override
            public UserPrincipal value() {
                return user;
            }
        };

        final Path target = Paths.get("whocares, I don't exist anyway");
        final Path symlink = Paths.get("/tmp/meh");

        Files.createSymbolicLink(symlink, target, attr);
    }
}
root@alustriel:/tmp# javac Test.java 
root@alustriel:/tmp# java Test
Exception in thread "main" java.lang.UnsupportedOperationException: 'owner:owner' not supported as initial attribute
    at sun.nio.fs.UnixFileModeAttribute.toUnixMode(UnixFileModeAttribute.java:74)
    at sun.nio.fs.UnixFileSystemProvider.createSymbolicLink(UnixFileSystemProvider.java:440)
    at java.nio.file.Files.createSymbolicLink(Files.java:996)
    at Test.main(Test.java:41)

Well, I kind of expected that.

The only situation I know where a symlink's permissions matters is in Linux's /proc/*/fd/ since the permissions of the symlink match the permissions with which the file descriptor was opened. But this is a systems generated symlink and is nothing like what the user can generate.

Is there any OS where a symlink's permissions actuall affect the behavior of the symlink and/or its target in any way, shape or form?

---

edit: well, I could change the owner of a symlink with chown but... Again, what's the point?

Answer 1

The Oracle docs say that this is just for future use:

The FileAttributes vararg enables you to specify initial file attributes that are set atomically when the link is created. However, this argument is intended for future use and is not currently implemented. (source; emphasis mine)

On a Mac, permissions seem to be settable, though they don't seem to have much of an effect. I created a file readable only by root, and two symlinks to it: one world-readable, one readable only by root. I could cat the file using all three, but ls -l only listed the link target for the world-readable link when I ran it as my user:

-rwxrwxrwx 1 root  wheel   7 Dec 21 21:32 actual
lrwxrwxrwx 1 root  wheel   6 Dec 21 21:33 link_for_all -> actual
lrwx------ 1 root  wheel   6 Dec 21 21:34 link_for_root

I couldn't find any other differences in behavior, but it's something, so perhaps you'll be able to use createSymbolicLink to create such a symlink in the future.