Sometimes I have two trees that used to have the same content, but have grown out of sync (because I moved disks around or whatever). A good example is a tree where I mirror upstream packages from Fedora.

I want to merge those two trees again by moving all of the files from tree1 into tree2.

Usually I do this with:

rsync -arv tree1/* tree2

Then delete tree1.

However, this takes an awful lot of time and disk space, and it would be much easier to be able to do:

mv -r tree1/* tree2

In other words, a recursive move. It would be faster because first of all it would not even copy, just move the inodes, and second I wouldn't need a delete at the end.

cp is terrible at this sort of thing because it typically destroys hard links / soft links and replaces them with individual files. Similarly it can't be trusted to keep ACLs straight and sometimes gets confused about sparse files.
–
chrisJun 28 '13 at 17:57

Howie, Welcome to ServerFault! Since your answer adds on to someone else's it might be best left as a comment to their answer. Or, you can edit your answer to fulfill the question in it's entirety. (If his question were deleted, yours should stand on it's own.)
–
Aaron CopleyJun 28 '13 at 17:44

This is not what I'm asking for. Your solution goes only one level deep and doesn't recurse into subdirectories.
–
Thomas Vander SticheleJun 12 '09 at 9:48

It doesn't recurse because with the subsequent mv command it's not necessary to recurse any further than one directory. However since you started with rsync I recommend my the --remove-source-files switch which will keep you with the tool you know plus it won't use as much space as the rsync/rm combination.
–
Server HorrorJun 12 '09 at 10:02

On another note: since I just read your post again regarding the merging you might want to play with -n or -i options from mv
–
Server HorrorJun 12 '09 at 10:03

I'm pretty sure you're not considering the fact that most of the tree already exists in the destination, so your first mv command will not work. Not sure what -n or -i will help here. Please try the example.
–
Thomas Vander SticheleJun 13 '09 at 7:41

The inode has the metatadata about the file (is it a file, a directory, a named pipe? Who owns it? What are the permissions? What blocks does that inode use?

Blocks are the things that actually contain the contents of the file.

So -- when you "mv" a file, all you're really doing is unlinking the first directory entry and relinking it somewhere else.

snoopy -> inode 333
woodstock -> inode 333

No data ever gets duplicated / copied. You create the link snoopy, then you create the link woodstock, and then you delete the link snoopy. (things are a bit different with directories because typically you can't make hardlinked directories, but even so the "link" name just changes).

What if you're moving from one filesystem to another? In the old days, mv would just thrown an error and make it explicit that you can't move a file from one filesystem to another. These days, it seems like mv silently copies the data then deletes the original.

In the old days, because you couldn't move data from one file system to another, you got in the habit of using idioms like

tar -cf - . | (cd /new/location && tar -xf -)

then you delete the old data. Part of the reason for using tar was that in the old days, cp would destroy metadata like "this is a symbolic link" and "that's a hard link" and instead you'd just get new copies of that file as regular files. Even still, you need to give "cp" flags to tell it to preserve that sort of structure.

There is no way to avoid "moving" lots of data if it is from one filesystem to another. It doesn't matter if you're using fancy new move or rsync or tar or cpio.

But, if you keep all the data in the same filesystem, this:

mv /filesystem-1/big/directory* /filesystem-1/big2/

that will be extremely fast because it is just changing the directory entries and not actually moving any real data.

There are other issues at play, such as what should you do if there is already a file / directory in the new location as well as the source location?