std::path::Path
contains 5 functions which are trivial aliases of functions in std::fs
:
and 3 which are convenience wrappers around std::fs::metadata
:
By my rough survey, these 8 are the only functions in std
outside of std::fs
, std::os::*::{fs, net}
, and std::process
that can initiate filesystem I/O. And they're surprising, because everything else in the std::path
module is just a pure data structures and algorithms that don't do any I/O.
These 8 functions are also unfortunate for the cap-std
project, which uses std::path::Path
in its sandboxed filesystem API, since it means that cap-std
's transitive API includes functions which unceremoniously do unsandboxed filesystem accesses. We could fix this by defining a custom Path
etc. that wrap std::path::Path
etc. and expose everything except these 8 functions. Alternatively, we could define a clippy lint our users could enable to warn about these 8 functions. However before we do either of these, I'm curious if there's any appetite for fixing the underlying cause.
Would would people think about a PR to deprecate these 8 functions? The 5 trivial aliases don't add value other than the ergonomics of eg. p.metadata()
vs. fs::metadata(p)
. For the 3 convenience wrappers, new functions fs::is_file
, fs::is_dir
, and fs::exists
could be added (though this is debatable, since these operations are somewhat prone to TOCTTOU bugs).