Add System.IO.FileSystem.Unix

[Petermarcu]

There are a bunch of common Unix file system constructs that we have no public surface area in .NET to control or interact with. For example, Unix permissions are a very common need for users/devs to interact with, but we don’t provide any surface area for getting (stat) or setting (chmod) these. We don’t provide surface area for changing ownership (chown), for creating symlinks (symlink) or hard links (link), etc. Devs can P/Invoke to these, but it’d be nice to have surface area for it to avoid devs needing to do that, especially given that some of these are impractical to P/Invoke to in any common way across Unix systems, e.g. the struct used by stat changes in both layout and size based on which distro/version you’re targeting, which is one of the many reasons we’ve moved away from direct P/Invokes to libc and instead have a think native shim. As a comparison, Mono has a library called Mono.Posix that provides essentially 1:1 wrappers between directly callable C# functions and the underlying POSIX functions they wrap.

[davidfowl]

It's also worth discussing how guard rails works in this scenario. If you reference this package because you want to chmod on linux but it isn't necessary does NuGet restore fail?

/cc @ericstj @anurse

[stephentoub]

guard rails

Yes, though it seems like that's an issue we already have and need to address if we haven't, e.g. an app using System.Threading.Overlapped.dll for async I/O on Windows, but that's not relevant to I/O on Unix.

[ellismg]

Somewhat related is #13879, which was a request to support enough surface area to run Mono.Posix on .NET Core. It might be interesting to consider just investing there as opposed to re-inventing the good work Mono has already done.

[stephentoub]

Sure, a library that simply exposed managed equivalents to the POSIX standardized APIs would be a fine approach. However, I believe just ensuring we have enough marshaling support in place for #13879 isn't sufficient to get that library working, as it's employing native Mono code to shim the APIs.

[ericstj]

I would imagine that we'd package such a contract with a RID-specific implementation. If someone we're consuming it they'd need a RID specific implementation, which would require multiple packages.

EG:
System.IO.FileSystem.Unix
ref/dotnet/System.IO.FileSystem.Unix.dll
runtimes/unix/lib/dotnet/System.IO.FileSystem.Unix.dll

System.Banana
ref/dotnet/System.Banana.dll
runtimes.json

{
  "runtimes": {
    "win": {
      "System.Banana": {
        "runtime.win.System.Banana": "4.0.0-beta-23325"
      }
    },
    "unix": {
      "System.Banana": {
        "runtime.unix.System.Banana": "4.0.0-beta-23325"
      }
    }
  }
}

runtime.win.System.Banana - no dependency on System.IO.FileSystem.Unix
runtime.unix.System.Banana - has dependency on System.IO.FileSystem.Unix

Ugly, but should work today.

[karelz]

We need API proposal ...

[danmoseley]

@eerhardt @stephentoub does this track anything not already covered by https://github.com/dotnet/corefx/issues/15289? Same question for dotnet/corefx#3188 I guess.

[stephentoub]

https://github.com/dotnet/corefx/issues/15289 is essentially a proposal for a solution to this issue. We can close this one.