Add Permissions argument to create_dir{,_all}

[nagisa]

Fixes #22415

[rust-highfive]

r? @pcwalton

(rust_highfive has picked a reviewer for you, use r? to override)

[nagisa]

r? @aturon

[aturon]

cc @alexcrichton -- was there any particular reason these were left out in the initial implementation?

[alexcrichton]

I actually intentionally left this out as I don't think we have any real concrete plans to expand Permissions into the huge array of what Windows supports. I was thinking that a std::os::unix function would arise to mkdir with a mode on Unix.

[aturon]

@alexcrichton

We don't have immediate concrete plans right now, but the point of the design, as I understood it, was precisely to allow growing those over time. In other words, by keeping Permissions abstract, we'd make it possible for functions like this to take a single, cross-platform, abstract Permissions type. We'd then offer some cross-platform APIs for setting/inspecting permissions, and extension traits for platform-specific work.

Put differently, create_dir_all and friends are perfectly cross-platform, even given a Permissions argument. It's the internals of Permissions that varies by platform.

We should implement Default for Permissions to make this very easy to use.

[mahkoh]

Why is 0o777 the default?

[nagisa]

Would defaulting to 0o0 and having to do create_dir{,_all}(path, default().mode(0o777)) (which would also make your app non-portable) instead of create_dir{,_all}(path, default()) be better?

[mahkoh]

There is no possible default value for permissions on linux. For directories you always want x but for files you almost never want x.

[mahkoh]

What is the status of this? This patch now only adds permissions to mkdir and nothing at all for windows. Furthermore there is no way to recursively create directories with permissions.

This is such elementary functionality that is seems crazy that Rust 1.0 will ship without it.

Combine this with the other issues that are popping up regarding the new io interface and it seems that radically changing io this short before stabilization was a mistake. If the normal create_dir_all ships without permissions then I guess in a few months you will add a new method create_dir_all2 that takes permissions.

[nagisa]

I’ll let somebody else to tackle this. I don’t want to have anything to do with anything related to Permissions any more.

[aturon]

@nagisa

I’ll let somebody else to tackle this. I don’t want to have anything to do with anything related to Permissions any more.

I'm sorry this was the outcome of the PR, but I'd be glad to take it over from here (or @alexcrichton may do so, since I'm on vacation right now.)

@mahkoh

What is the status of this? This patch now only adds permissions to mkdir and nothing at all for windows. Furthermore there is no way to recursively create directories with permissions.

Last week we were focused on putting out alpha2, so this was explicitly put on hold (in communication with the PR author).

As @alexcrichton explained, there has never been functionality in Rust for doing interesting things with permissions on Windows (and this is the case in many other std libraries as well). We intend to provide APIs for Windows permission manipulation, and perhaps eventually ones with real cross-platform semantics (that don't simply drop the permissions on the floor on Windows), but this will take time.

This is such elementary functionality that is seems crazy that Rust 1.0 will ship without it.

My preference is to provide create_dir and create_dir_all taking a Permisisons argument, with the usual std::os::unix hooks to create the Unix-specific permissions. That was certainly the intent of the RFC, but didn't make it into the initial implementation (probably because the RFC didn't give the signature explicitly). I consider this a bug in the implementation of the RFC.

Combine this with the other issues that are popping up regarding the new io interface and it seems that radically changing io this short before stabilization was a mistake. If the normal create_dir_all ships without permissions then I guess in a few months you will add a new method create_dir_all2 that takes permissions.

As we announced previously, the reason for launching alpha2 is precisely to have more time to stabilize the new IO APIs. The previous incarnation of IO had myriad known problems, and by and large the changes have moved things in a more conservative direction.