Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Once upon a time, mv was "a stupid system call interface to rename(2)". However, some users didn't like having to think about whether the source and destination were on the same mountpoint, so someone decided to make mv more complex[1]. The Unix designers lamented the growing complexity, but the great many naive users celebrated the change, and demanded that all mv implementations do that.

[1]: I believe GNU mv was the first to do that, but I could be mistaken.

Edit: As userbinator points out, this isn't totally true. I still believe it is true for moving directories, but for files, mv has copied them since at least Research UNIX V4 (1973), this being implemented by either Ken Thompson or Dennis Ritchie themselves.



> However, some users didn't like having to think about whether the source and destination were on the same mountpoint

That's actually a good thing, because it makes scripts more composable. Imagine you wrote a script that contains a buried mv somewhere in it, then you'd have to document this restriction all the way up to the end users of your script. If the mv command doesn't handle the mount-point-spanning case, then this functionality will have to be repeated in all scripts that use mv (which would be a disaster).

> the great many naive users celebrated the change

That's a very arrogant, unwarranted thing to say.


> > However, some users didn't like having to think about whether the source and destination were on the same mountpoint

> That's actually a good thing, because it makes scripts more composable.

I argue that it actually precludes any form of composability:

http://jstimpfle.de/fun/composability.html


I didn't say it was a bad change. But, even good changes should make one frown at the groing complexity.


> frown at the groing complexity

When I have the chance to remove replicated complexity from a myriad of places and to concentrate it on one central point (and make the interface simpler and more consistent in the process), I don't frown, I laugh with joy.


But for more than a decade, it was a bug that moving across devices screwed up ownership. So then you still have to to be aware of whether you are moving across devices, but now if you are but don't realize it, it automatically screws up your data.


That must be ancient history, because even Unix V6' mv would copy-delete (it didn't support moving directories to different parts of the tree though; that would be introduced in V7.)

http://man.cat-v.org/unix-6th/1/mv

http://cm.bell-labs.com/7thEdMan/v7vol1.pdf

http://man.cat-v.org/unix_8th/1/mv


I just did some digging. You're right that copying to different filesystems was introduced in Research UNIX.

In V5 and V6 mv, they actually call `execl("/bin/cp"` to do the copy!

Note that neither V5 nor V6 do this for directories though, only regular files (which I guess is implied by the fact that they force the parent directory to be the same for directory moves).

I can't find the source or binaries of V3 mv, but the V3 manual does not mention copying (the text in the V6 manual originated in the V4 manual).

Edit: more:

V7 gained support for moving a directory within the same device, but it still didn't support copying directories across devices.

I can't find much on Research UNIX >= V8, but they were based on BSD.

Edit: even more:

Copying directories in mv was first added to BSD in 1989 by Ken Smith <kensmith@cs.buffalo.edu> (committed by Keith Bostic). It used `cp -R` to do the recursive copies.


> I believe GNU mv was the first to do that, but I could be mistaken.

I was mistaken: BSD mv gained copying directories across devices in 1989, GNU mv didn't get that until 1998




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: