8

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?

Community
  • 1
Andrew
  • 16,855
  • 1
    mv is not actually recursive. It is merely moving one thing, the inode of the directory you specify. Everything under that directory remains untouched. Think of it as cutting a branch off a tree, and attaching it to a different place on the tree: you merely make one cut, rather than doing something to each twig & leaf. – jamesqf Mar 30 '15 at 18:29
  • @jamesqf Thank you! I am a relatively novice user of Unix and Linux; is the inode of the directory sort of like a pointer to the data? – Andrew Mar 30 '15 at 18:59
  • I don't think that's the question, but mv a.txt b.txt can be dangerous because it deletes b.txt without warning. Okay, so does cp a.txt b.txt. – Eric Duminil Jun 16 '20 at 16:16

1 Answers1

9

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).

Community
  • 1
dhag
  • 15,736
  • 4
  • 55
  • 65
  • Thanks so much! When you say, "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," does that mean that cp might actually cause more fragmentation, etc than mv? – Andrew Mar 30 '15 at 18:56
  • 1
    I was thinking of other users of the same cluster doing writes concurrently with your cleanup operations, but it is also true that copying files is going to be a lot more write-intensive than moving them, and is more likely to cause fragmentation (although fragmentation generally isn't a big concern on typical Unix filesystems). – dhag Mar 30 '15 at 19:06
  • Note that POSIX only guarantees atomicity when the target already exists. It doesn't when the target doesn't exist, though most unix systems do offer this guarantee for their native filesystems. – Gilles 'SO- stop being evil' Nov 09 '16 at 23:34