Linux command: mv

Moving a file feels even simpler than copying one. You type mv, the old name, the new name, and press Enter. Nothing seems to happen, and that is the whole surprise: on the same disk, mv does not move a single byte of your data. It changes a name in a list and finishes instantly, whether the file is two kilobytes or two hundred gigabytes. The same command also renames files, quietly overwrites whatever was in its way, and has no undo. Learning mv properly means learning what a filename really is in Linux.

2. Where the Name Comes From

The name mv is simply short for move. As with most early Unix commands, there is no hidden meaning; the two letters are the first and last consonants of the word.

mv  =  MoVe

Early Unix was typed on slow teletype terminals that printed every character onto paper, so short command names saved both typing and ink. That is why the command is mv and not move. The same instinct gave us cp (copy), rm (remove), and ls (list): a whole vocabulary of two-letter verbs.

One small point of confusion is that mv also renames files, yet there is no separate rename command for the everyday case; renaming is just moving a file to a new name in the same directory. The manual page even spells this out in its title: "move (rename) files". If you ever move to Windows, note that its shell splits the job into move and rename; Unix treats them as one.

4. Simple Use Cases

4.1 Renaming a File

Give mv a source and a new name, and it renames the file. In the examples below, the line that starts with $ is what you type; a command that prints nothing simply succeeded, which is the normal Unix way of saying "all good".

$ mv notes.txt notes-final.txt
$ ls
notes-final.txt

Notice that the original name is gone. Unlike cp, which leaves you with two files, mv leaves you with one: the same file under a new label.

4.2 Moving a File Into a Directory

If the destination is an existing directory, mv puts the file inside it and keeps the original filename. This is the most common everyday use: filing something away into a folder.

$ mv report.txt /home/peter/archive/
$ ls /home/peter/archive/
report.txt

The trailing slash on archive/ is a good habit: it makes your intent clear and, if you mistype the folder name, mv fails loudly instead of quietly renaming report.txt to a file called archive.

4.3 Moving Several Files at Once

When you give more than two arguments, mv treats the last one as a destination directory and moves every file before it into that directory. This is where the "last argument is the destination" rule really matters.

$ mv index.html style.css script.js /var/www/site/

All three files land in /var/www/site/. If that last argument is not an existing directory, mv refuses and prints an error, which is a helpful safety net:

$ mv a.txt b.txt nodir
mv: target 'nodir': No such file or directory

4.4 Moving a Directory: No -r Needed

Here is the first real difference from cp. To copy a directory you must add -r, because copying a folder means duplicating everything inside it. Moving a directory needs no such flag. Because a move on the same filesystem only changes one name, moving a folder of ten thousand files is exactly as instant as moving one file.

$ mv project /home/peter/projects/
$ ls /home/peter/projects/
project

The whole tree comes along, instantly, because nothing inside it actually moved. Only the directory's own entry changed to point at a new parent. That single fact explains most of what makes mv feel almost magically fast.

Renaming a file and moving a file are the same operation. Whether the destination is a name or a directory, and whether it already exists, quietly changes where your file ends up. Section 6 returns to that trap.

6. Advanced Use Cases

6.1 The Directory Trap: Destination Exists or Not

This is the single most confusing thing about moving directories, and it catches everyone at least once. When the destination is a directory name, the result depends on whether that directory already exists.

$ mv src dst        # dst does NOT exist: src is renamed to dst
$ mv src dst        # dst DOES exist:     src is moved INSIDE dst
                    #                     giving dst/src

Run the same command in two different situations and you get two different layouts. If dst does not exist, src simply becomes dst. If dst already exists as a directory, src is moved inside it, producing dst/src. When a script mysteriously buries a folder one level too deep, this rule is almost always why.

To force mv to treat the destination as a plain name and never move "into" it, use -T (short for no-target-directory):

$ mv -T src dst     # always rename src to dst, never dst/src

The mirror image is -t (short for target-directory), which names the destination directory up front so every other argument is a source. This is essential when building commands with find and xargs, where the directory must come first:

$ find . -name '*.log' -print0 | xargs -0 mv -t /var/log/archive/

6.2 The Trailing-Slash Detail: --strip-trailing-slashes

A trailing slash usually signals "this is a directory". Shell tab-completion often adds one automatically. But a stray slash on a source name can change how mv behaves, especially with symbolic links to directories. The --strip-trailing-slashes option removes any trailing slashes from the source arguments so they are treated as plain names.

$ mv --strip-trailing-slashes linkdir/ newname

You will rarely need this by hand, but it is worth knowing it exists when a scripted mv behaves oddly on names that a completion added a slash to.

6.3 Moving Is Renaming, So Permissions Come Along

Because a same-filesystem move never creates a new file, the file keeps everything: its permissions, owner, timestamps, extended attributes, and inode number stay exactly as they were. There is no -p flag on mv as there is on cp, and none is needed, because nothing is being recreated. The moment mv crosses to another filesystem, though, it must create a new file at the destination, and then it works hard to reproduce those attributes on the copy before deleting the original.

This is why the inode number, which you can see with ls -i, survives a rename on the same disk but changes after a cross-disk move: in the first case it is the same file, and in the second it is a new one.

6.4 Who Is Allowed to Move a File

Because a move edits directory entries rather than the file itself, the permission that matters lives on the directories, not the file. To rename or move a file you need write and execute permission on the source directory, and on the destination directory too. You do not need to own the file, and you do not even need permission to read or write its contents. This surprises many newcomers.

$ ls -l
-rw-r--r-- 1 root root 42 Jul  7 10:00 owned-by-root.txt
$ mv owned-by-root.txt renamed.txt    # works: you have write access to the directory

The one exception is a directory with the sticky bit set, such as /tmp. There, only a file's owner (or root) may rename or remove it, which is exactly what stops users on a shared system from moving each other's files out of /tmp.

6.5 Moving a Symbolic Link

When the source is a symbolic link, mv moves the link itself, not the file it points to. The target file stays exactly where it is, and the link simply gets a new name or location while still pointing at the same path.

$ mv mylink newlink    # the link is renamed; its target is untouched

Note that a symlink stores its target as a path, not as an inode. If that path was relative, moving the link to another directory can leave it pointing at nothing, because the relative path is now resolved from a different place.

8. Best Practices

• Assume the destination will be overwritten. Before mv a b, ask what b holds now. There is no undo. Use -i when working by hand and you are unsure.
• Use "temp file then mv" to update important files. Write the new version alongside the original and rename it into place; the atomic swap means readers never see a half-written file.
• Watch the directory-exists trap. With mv src dst, the result differs depending on whether dst exists. Use -T when you mean "rename to exactly this name".
• Add a trailing slash to a destination directory. mv file dir/ fails loudly if dir is missing, instead of silently renaming file to dir.
• Copy, verify, then delete for cross-disk moves. A move between filesystems is a non-atomic copy plus delete; for large or important data, prefer rsync and remove the source only once you have checked the result.
• Reach for the manual without hesitation. The habit that separates beginners from professionals is typing man mv the moment a question comes up.

$ man mv                            # the full manual page
$ mv --help                         # a quick flag summary (GNU)
$ info coreutils 'mv invocation'    # the verbose GNU manual

10. Summary

The mv command looks like it does nothing, and on the same disk that is nearly true, which is exactly what makes it such a clean lesson in how Linux separates a file from its name.

• mv is short for "move". It renames a file or moves it to another place; both are the same operation, changing where a name points.
• On one filesystem it moves only the name, using an atomic rename(), so moving a huge file or a whole directory is instant and needs no -r.
• Across filesystems it cannot rename, so it copies every byte and deletes the original, which takes time and is not atomic.
• The last argument is the destination. Moving into an existing directory keeps the filename; moving several files needs the last argument to be a directory.
• Whether the destination directory already exists changes where the file lands; use -T to force a plain rename and -t to name the target directory first.
• -i asks before overwriting, -n skips existing files, -f forces, -v shows progress, -b keeps a backup, -u moves only newer files.
• Because a rename is atomic, "write a temp file, then mv it over the target" is the safe way to update a file other programs are reading.
• The permission to move a file lives on the directories, not the file: with write access to a folder you can move a file you do not own, unless the sticky bit (as on /tmp) forbids it.
• There is no undo and no trash can; mv a b destroys whatever b was, silently.
• Know where mv stops: rename for pattern renames, rsync for safe cross-disk or remote moves, cp to keep the original.
• When in doubt, type man mv.

This is the quick reference worth keeping:

mv a b               rename a to b (overwrites b silently)
mv a b c dir/        move several files into a directory
mv dir dst/          move a whole directory (no -r needed)
mv -T src dst        rename src to dst, never dst/src
mv -t dir/ a b c     name the target directory first
mv -i a b            ask before overwriting b
mv -n a b            skip if b already exists
mv -b a b            back up the old b as b~ before overwriting
mv -u a b            move only if a is newer than b
mv -- -x.txt dir/    move a file whose name starts with a dash
mv tmp real          the atomic-swap trick for safe file updates

Small commands like mv hide a surprising amount of how Linux is built, and a single careless move can undo hours of work with no way back. If your servers matter and you want them maintained by someone who understands what is really happening underneath, that is exactly the kind of work I enjoy helping with.