I don't suppose the kotlin team has any interest i...

# stdlib

[groostav]

I don't suppose the kotlin team has any interest in creating multiplatform file permission manipulation?

I'm trying to change the permissions on a path created in oracle java-21 Files.createDirectories. They have their PosixFileAttribute stuff which makes it elegant enough (still pretty ick) for linux... but you're SOL on windows.

We do a fair bit of native code stuff here so I figured I'd hit JNA's nice Win32 wrapper to see if I could write some native bindings to do it myself...
https://learn.microsoft.com/en-us/windows/win32/secauthz/modifying-the-acls-of-an-object-in-c--

microsoft's sample code does not give me hope. It contains a goto.

But this does make me wonder what IDEA does itself, being a kotlin/java app and --im sure-- having a bunch of argument with file access rights.

[jw]

If this lived anywhere to start, it would be in kotlinx-io not the stdlib.

That being said, any abstraction over these systems is likely to contain so much complexity it's unwieldy, or be so neutered it's not that useful.

I find moving the abstraction into my application domain means the implementations can vary wildly but the common API remains nice and high-level.

[jw]

Okio punted on this because it's so complex. I would expect kotlinx-io maybe to do some neutered version, but I actually hope they don't.

The models don't align well, and it gets weirder once you start putting S3 buckets or zip files behind file systems.

[groostav]

I mean my hope was simply that somebody had written a library wrapping JNA that simply gave me a WindowsFileAttributes view that I could simply ask for. I presume this stuff is all service-located up the wazoo, and will throw Unsupported if you cant see it.

But like... blyeh. I guess this I'm just struggling with one of the core conceits of the jvm programming model. A heavy runtime that gives you reasonably deep integration into most things, and then "go solve it yourself in native code" for places where you cant, which in my experience is incredibly rare.

[groostav]

Sorry but to your point about unwieldy complexity, the Attributes view seems like a reasonable strategy. the APi would expose some kind of device for making users explictly select for the platform --ideally using a mechanism other than a cast, and that mechanism could be implemented by a service locator.

One could then provide something that simply elegates to exec("chmod..." or exec("icacls..." , or an implementation that calls ustd/Win32.

To your point about ZipFiles or S3 buckets, I think your right it would be complex, but in the selection operation you would either get a Result.Failure or an UnsupportedOperationException or whatever.

So I guess what I want is something like this:

val path: Path = ...

when(path.filesystem.indicator){
  is WindowsNTFS -> {
    val windowsControl = NTFS.permissions(windowsControl)
    //...
  }
  is PosixFS -> {
    // trying to wrangle the zoo that is ext to ZFS might be tricky i suppose, but it seems do-able.
  }
}

Like my point is I don't need a nice common API that will try to determine who "group" is and try to universal-ize permissions, let them be specific and don't bother with a shared API.

but on the default jvm, and with kotlin, I have no mechanism to see windows permissions. That seems kinda lame.

[Filipp Zhinkin]

I'm trying to change the permissions on a path created in oracle java-21 Files.createDirectories. They have their PosixFileAttribute stuff which makes it elegant enough (still pretty ick) for linux... but you're SOL on windows.

On Windows, NIO provides ACL attrs view:
https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/nio/file/attribute/AclFileAttributeView.html

Elegance disappears there completely, but it should solve the problem

[groostav]

This is what i was looking for. Thank you