Is there really no std copy_dir?

Guys, it seems to me that there isn't std::way to copy_dir. This to me is huge oversight as copying content of a dir is something that isn't unique or rare and everyone should cater this functionality for their own needs.
I know one can iterate over dir and copy the content, but this means that everyone needs to manually write that iterating code. This should be in std::
Or I simply can't find it?

The standard library is voluntarily kept small.

Maybe look at this crate fs_extra — Rust filesystem library //

Anyway, that's not the kind of baked-in functionality one would typically expect in a programming language. I don't think I know any mainstream language apart from python and ruby (and arguably the different shells) with utilities like that.


Why do we have copy file though?

Because copying a file is generally a straight forward operation.

Iterating a directory is not difficult to do, yet there are lots of considerations that would bloat the code, e.g. do you copy symlinks or traverse them, do you descend into other mounted filesystems or stop at mount boundaries, what traversal ordering do you use, etc. All these would serve to bloat the code, yet are not complex in and of themseleves to implement. These things make it better suited for ecosystem implmentation instead of being part of the std library.


I disagree with that completely.
Those "considerations" you've mentioned could be an CopyOption param to copy_dir fn. Done. Once for everyone to use.
Instead, everyone will have to do it manually...

...and if those options don't cover what you are looking for?

1 Like

@piter76, please don't get into arguments with people who are just trying to answer your questions.

Here's another crate that looks useful:

This does seem like something that might be worth adding to the standard library at some point, if there's a design that addresses all the common use cases and is proven enough that we never expect to have to change the API.

Then, if user needs some really specific behaviour, then yes, if you need something unusual you should implement for yourself. But standard, most common scenarios, should be covered by std, not left to everyone to implement, better or worse, 1000 times same thing.

But that's my point. There is no really 'standard' way to copy a directory, except maybe in the most trivial of scenarios, ignoring tons of filesystem and OS differences. A solution which doesn't have an obvious, single, correct implementation is something that shouldn't be in the std library IMHO.


I'm serious, folks. Don't respond just to argue, and don't post unstructured criticism. Flag inappropriate replies and do not respond to them. Email me or the mods if you need clarification on this. [Several comments above have been deleted.]


Thanks, but this is not the point. Obviously I can iterate over dir myself, but the point is that this should be std functionality. To me it is so common that the fact that it isn't in std is buffling.

The Rust standard library is smaller and missing many things compared to other languages, for two main reasons:

  • It is young and still growing.
  • Using an external crate is relatively low-cost, and there are also some benefits to putting things in external crates.

Adding things to the standard library is done slowly and deliberately because every API in the standard library is essentially frozen forever.

That's not to say we can't add this feature the standard library. I think copy_dir is a decent candidate for inclusion, since it is fairly widely useful and abstracts over platform-specific code that would benefit from being maintained and tested on all supported platforms.

A good first step to adding a feature like this to the standard library is to start with an external crate, where both the API and implementation can be tested and polished. If it proves widely useful and no longer needs any changes, and there are benefits to including it, then it can be proposed for inclusion.


That right there is I think the best approach I've seen in a language ecosystem.

Step 1:
Write it as a third party library.
Step 2:
Prove it is generally useful, wildly popular, and above all completely stable.
Step 3:
Propose inclusion into std.


I 'd like to add that if step 2 isn't accomplished, then it shouldn't be in std, but even if step 2 is accomplished, things are probably just fine with leaving it as a working, stable, third-party library, unless as mbrubeck said: "and there are benefits to including it" That should be a high bar, keeping std simple and clean instead of filling up with cruft and long-since-deprecated ways of doing things.


Yes, I agree with those arguments. It simply surprising that it isn't already in std.