Open
Description
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 oflibc::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 aPermissions
structure.- File types are currently limited to
is_file
andis_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 likeCreateDirOptions
as we haveOpenOptions
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 apath
accessor. For example on windows we could probably provide ametadata
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 toread_dir
).copy
is fairly simplistic and doesn't necessarily fit the bill for all use cases. It would be nice to have aCopyOptions
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 aWalkOptions
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 instd::fs
? The possibilities of temporary files is also quite intriguing as well, especially on linux withO_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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Metadata
Assignees
Labels
Relevant to the library API team, which will review and decide on the RFC.Relevant to the library API team, which will review and decide on the RFC.