Copying and moving directories

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, February 17, 2017 11:00:30 Chris via Digitalmars-d-learn wrote:
> On Thursday, 16 February 2017 at 17:06:30 UTC, Jonathan M Davis
>
> wrote:
> > Well, there's zero difference between renaming the file or
> > directory and moving it. It's simply a difference in name.
> > rename actually comes from POSIX, where rename is used in C
> > code, and mv is used in the shell. So, I guess that you can
> > blame POSIX. But there really isn't any reason to have a mv or
> > move function in addition to rename.
>
> `mv` or `move` would be more intuitive. I actually looked for
> names similar to the operations available in the shell (cp/copy,
> mv/move). It took me a few minutes to realize I had to use
> `rename` (which is poorly documented). But it is
> counter-intuitive. When you use a GUI, `rename` doesn't change
> the location. `rename` is a bit "techy", you have to go "wait a
> minute, when you think about it, rename should do the same". But
> that's not good enough for a library function. One of D's slogans
> is `simple things should be simple`, so moving a file should be
> `move(dir, toDir)`. Seriously, you don't want to spend much time
> on stuff like that.

Well, there's a _long_ history of it being called rename on POSIX systems,
and since the D function is a simple wrapper around rename, it makes sense
that it's called rename, much as I agree that the name isn't the best for
anyone not familiar with the C function. Regardless, changing it now would
break code, and at this point, we pretty much never rename public symbols
in Phobos just to improve their names.

> > If you want mv instead, just alias rename to mv.
> >
> > However, I would point out that rename has the problem (at
> > least on *nix - not sure about Windows) that it can't move
> > across filesystem boundaries. I think that at some point, an
> > alternative which did work across filesystem boundaries was
> > proposed, and that may have been called move. It's not
> > currently in Phobos though.
>
> That is actually a bit of a problem. First, I might want to store
> backup files on a different device. Second, loads of applications
> need this nowadays to interact with MP3 players, ebook readers
> etc.

Yes, it is a problem, but we would have to implement our own function to do
it, because the underlying system calls don't support moving files across
filesystem boundaries. At that point, what you're fundamentally doing is
copying the file or directory and then deleting the original. It's not
actually possible to simply move files across filesystem boundaries (which
is why the system call works the way it does). Any language or library which
supports moving across file system boundaries implemented its own solution
rather than simply using a system call.

And we probably should add some sort of move function to std.file that works
more like mv (leaving rename to wrap the system call and act like someone
familiar with the POSIX function would expect while providing a more
user-friendly - but somewhat less efficient - function for moving files from
anywhere to anywhere), but thus far, no one has added such a function to
Phobos. We don't even have one that copies recursively (there's a PR in
limbo for that one, but there were issues with the implementation and
disagreement on how it should work - I basically wanted it to act like cp -
which the PR doesn't - whereas others thought that that was a terrible
idea). So, while what std.file has is nice and cross-platform and more
pleasant than dealing with the underlying system calls even when you don't
care about being cross-platform, it could definitely use some work to make
some aspects of it more user-friendly. Most of what is there are fairly thin
wrappers around systems calls.

Sadly, my workaround has generally been to use std.process to use cp or mv,
but there are also plenty of cases where I would have had to do that anyway,
because I needed sudo (which AFAIK can't be done without the shell - though
I'd love to learn how if it is).

- Jonathan M Davis