std::fs::create_dir* should take permissions

[aturon]

The new fs module does not provide a way to create a directly with given permissions, which is especially painful for create_dir_all. It should.

The RFC specified that these functions should resemble those in old_io except for a generic bound, so it's not clear why the permission argument was droppped.

[aturon]

cc @alexcrichton @mahkoh

[nagisa]

We can create a File with provided permissions via OpenOptions. I suggest extending this struct to also provide a method to create a directory.

[aturon]

@nagisa Hm, but the problem is that methods like create_dir_all are convenience which actually create a whole host of directories. The old API just took a permissions argument; why not do so here?

[nagisa]

If I remember correctly there was a lot of discussion (on the RFC) regarding Permissions, because they are not quite supported on Windows (or even some FSes on Unixes) therefore they are only exposed as an extension in respective sys modules.

[nagisa]

This is a relevant comment thread

[aturon]

@nagisa Oh yes, this was definitely a big part of the RFC effort.But the result was that we have permissions, we just don't expose very much of them at the std::fs level.

That is, the Permissions structure is pretty opaque -- but we absolutely can use it in a cross-platform way, and platform-specific extensions allow to to interact with it in a richer way.

[aturon]

Nominating for 1.0-beta P-backcompat-libs.

[mahkoh]

It seems that both Permissions and OpenOptions is unusable right now. There is no way to cross-platform create files that are not-world-readable/writable or executable.

I've checked Go and Python (and C via mingw) and neither of those seem to have this problem.

This seems to be a serious oversight in the RFC.

[alexcrichton]

@mahkoh you can't really compare to what other languages do because they all ignore the mode argument on windows (at least from what I've found). For example here's the source for Go and Python.

I also encourage you to be a little more specific instead of saying that the structures are "unusable right now". When you say "there is no way to cross-platform create files that are not-world-readable/writable or executable" it's because there isn't one in the manner of permission bits on posix. I would also encourage you to explore the std::os::unix module to see that you can set the mode on Permissions and on OpenOptions.

I would certainly believe that we could add a few more unix-specific extension traits, but I would encourage you to be a little more constructive in what you're requesting.

[mahkoh]

I am not talking about unix specific code. Functions that use std::os::unix will not compile on Windows, I assume. I'm talking about cross platform code that doesn't need platform specific functions.

@mahkoh you can't really compare to what other languages do because they all ignore the mode argument on windows (at least from what I've found).

Why does this mean that it cannot be compared?

[pnkfelix]

1.0 beta, needs-decision, P-backcompat-libs

[aturon]

I'm going to close this issue. The plan is to instead follow a design similar to opening a file, where we can provide conveniences with reasonable per-platform defaults for create_dir and create_dir_all, and then have a builder-style API (CreateDirOptions or some such) that allows per-platform customizations of things like permissions or security attributes, etc.

@alexcrichton will be following up with an eventual RFC before 1.0.

[alexcrichton]

I have opened an issue in the RFC repo to track this functionality.

[SteveLauC]

For someone finding this issue and thinking we still don't have this, we already had this stuff since 1.6.0:

• fs::DirBuilder

• unix::fs::DirBuilderExt

  pub trait DirBuilderExt {
      fn mode(&mut self, mode: u32) -> &mut Self;
  }