Expand the scope of std::fs

[alexcrichton]

Right now the API of std::fs is fairly conservative. In some places it may even be a little bit too conservative. After re-scrutinizing the API and looking at some others I've come to think that we may wish to act on expanding the surface area before 1.0. For now I'm opening this issue as a tracking issue for all known expansions to the std::fs API that are desired. I'll update the list below over time.

• Metadata is a bit too opaque. There's lots of other information from the OS that we're getting, especially on unix. For example we're only providing a few fields of libc::stat and there should in theory be a method of accessing all of the internal fields.
• Permissions is also quite opaque. Although there are platform-specific accessors, the accessed type may wish to change. Additionally, there should also be at least one cross-platform constructor of a Permissions structure.
• File types are currently limited to is_file and is_dir accessors. There are many more file types on unix (and possibly on windows) which are not being exposed.
• On unix one can create a directory with a specified mode, and on windows one can create a directory with a set of security attributes. Neither is currently possible with the create_dir APIs that we have. It would be nice to have something like CreateDirOptions as we have OpenOptions which is then extensible with platform-specific traits. Another example option, which C++ has, is to specify a "template directory" to draw permissions from.
• DirEntry is quite conservative in only exposing a path accessor. For example on windows we could probably provide a metadata accessor at essentially no cost. There's also a bit of more free information we could expose on unix but it may be nice to have more cross-platform functionality as well. Another example of something we don't expose is just the filename itself Add get_entry_name function #927 (not the full pathname as joined from the initial call to read_dir).
• copy is fairly simplistic and doesn't necessarily fit the bill for all use cases. It would be nice to have a CopyOptions structure to customize how a copy is done as well as supporting other operations like a recursive copy, copy-via-hard_link, copy-via-soft_link, etc.
• With a lack of normalization on paths by default, it would be nice to have an analog of C++'s equivalent function which tests if two paths point to the same file.
• Soft link (symlink) support is pretty lacking today. There is no method to get the metadata about a soft link (as opposed to the file that it points to) for example. It is also not currently possible to test whether a file is a soft link.
• walk is not necessarily suitable for all cases and may desire a WalkOptions structure to configure how a walk is performed as well.
• Binding realpath would be nice to have (resolving all soft links in a path) - #11857
• Temporary files and directories are currently not implemented, and this space should at the very least be explored. Right now we have a tempdir crate on crates.io, but maybe it should be in std::fs? The possibilities of temporary files is also quite intriguing as well, especially on linux with O_TMPFILE for example.

To be clear I don't think that this red-hot-second is the time to pursue these changes. There are still many more APIs in the standard library which have a more pressing need for attention. I want to ensure that all this functionality is not forgotten, however.

[alexcrichton]

cc @aturon

[alexcrichton]

I should also be clear that I plan to write an RFC for this in the future, just not at this time :)

[blaenk]

sounds great

👍 Thanks for covering this.

[GuillaumeGomez]

I'm looking forward to it ! It sounds very promising.

[codyps]

DirEntry reminded me that posix has functionality allowing for file operations relative to a directory handle, which are sometimes required for safe file system access.

To support that type of thing (even externally) it'd be useful if DirEntry exposed a method to obtain the actual value of the DirEntry (ie: the name of the file relative to the directory) rather than just the full path.