Are there any dangers in using mv (instead of cp followed by rm)

mv

I'm a graduate student with access to a research group Linux cluster at my university. Over the years, I have accumulated many directories — I guess "folders" is Windows/Mac terminology? — in my home directory (~). When I'm working on a new simulation, I create a new directory in my home directory using mkdir and then run the simulation in that directory.

But over time, I have accumulated many such directories in my home directory. Now I want to move some of the directories into subdirectory. For example, I might want to create a new directory called simulations1_10 and then move the directories simulation1, simulation2, … , simulation10 into that directory — so that the root of my home directory is more organized.

To do this, I could use cp. For example:

cp -r simulation1/ simulations1_10/

would copy the directory simulation1 (and all its contents) to the directory simulations1_10. I could then remove simulation1.

But, my transfers aren't crossing filesystem boundaries, so mv is much faster than cp. (mv of course also allows me to avoid the remove step.) For example:

mv simulation1/ simulations1_10/

does the trick quickly (and unlike cp, mv is recursive by default). According to this answer to this question, mv is much faster because it "just updates the inode database in various directories."

My question is, are there any dangers in using mv?

I think that one danger is that if mv is interrupted (due to power failure, user pressing Ctrl+C, etc) during a transfer, the file might become corrupted in both the source and the destination. Is this correct?

Also, if I use mv a lot, is there a chance that the "inode database" will be updated too often, causing disk fragmentation or other hard drive/filesystem problems?

Best Answer

The rename function (that underlies the command mv, "The mv utility shall perform actions equivalent to the rename() function") is atomic (see POSIX http://pubs.opengroup.org/onlinepubs/009695399/functions/rename.html, that refers to the C standard):

This rename() function is equivalent for regular files to that defined by the ISO C standard. Its inclusion here expands that definition to include actions on directories and specifies behavior when the new parameter names a file that already exists. That specification requires that the action of the function be atomic.

(But see this for caveats: https://unix.stackexchange.com/a/322074/88983.)

Interrupted operations, be it by Ctrl-C or otherwise, should never result in partially-transferred files. Indeed, as you mention, a single-filesystem mv doesn't actually copy any file contents, only file metadata. The worst that should happen on that front is to see partially-moved directories (if you do mv a b c dest, it is possible to interrupt and have only e.g. a moved into dest, but all files and their contents will have been moved properly), not partially-moved regular files.

About your inode side question, I would say it's generally not a concern; updating inodes to move just a few directories around is a low-overhead, routine operation (file content writes happening on the same filesystem should be a much greater potential performance hit or fragmentation cause, depending on the specific filesystem type).

Related Question