The name FileMv has two parts: file is obvious, but Mv points to a Unix command that is more than fifty years old. mv (short for move) is the command used on Linux, macOS and every Unix-like system to move and rename files. It does one thing, does it well, and doesn't ask needless questions. That is what we wanted from a free file sharing service too: a file going from point A to point B, without ceremony. This article covers where mv came from, what happens behind the scenes when you run it, and walks through its most useful options with examples.
A command that has done the same job for fifty-five years
mv is as old as Unix itself. It already appears in the first manual of the system Ken Thompson and Dennis Ritchie wrote at Bell Labs, published in November 1971. The same manual lists cp (copy), rm (remove), ls (list) and cat; the names haven't changed since.
Why are the names so short? Because back then people didn't use these machines through a monitor but through a Teletype, an electromechanical typewriter terminal. A Teletype Model 33 printed about ten characters per second, the keys were stiff, and every keystroke ended up on paper. Under those conditions typing mv instead of move wasn't laziness, it was common sense. The two-letter command names are a leftover from that era, and by the time terminals got faster they were so deeply ingrained in users' fingers that nobody wanted to change them.
mv is also a textbook example of the Unix philosophy. Doug McIlroy, one of the leaders of the Unix team, summed it up in 1978: write programs that do one thing and do it well. mv doesn't compress, scan for viruses or send notifications. It moves. Everything else is done by other programs, which users can combine however they like.
Today Linux typically runs the GNU coreutils mv (written by Mike Parker, David MacKenzie and Jim Meyering), while macOS and the BSDs ship a version from the BSD lineage. Both behave the same way at their core, but some of their options differ; more on that below.
What does mv actually do?
mv is for two things, and the two are really the same thing:
mv report.pdf archive/ # move into another directory
mv report.pdf report-v2.pdf # rename
mv report.pdf archive/2026.pdf # move and rename at once
Unix has no separate "rename" command because it doesn't need one: renaming a file and moving it are the same operation. To see why, we need a quick look under the hood of the file system.
The inode and the directory entry
In a Unix file system, a file's content and its name live in separate places. The file's data and properties (size, permissions, modification time, where its blocks are on disk) are described by a structure called an inode. The file's name, by contrast, is just an entry in a directory: a line saying "the name report.pdf points to inode 4,718,233".
When you move a file within the same file system, mv doesn't touch the content at all. It only rewrites the directory entry: it removes the name from one directory and adds it to another. That's why you can move a 50 GB video file on the same disk in the blink of an eye, while copying it would take minutes.
You can check the inode number yourself and see that it doesn't change after the move:
$ ls -i video.mp4
4718233 video.mp4
$ mv video.mp4 movies/
$ ls -i movies/video.mp4
4718233 movies/video.mp4
The rename() system call
The earliest Unix versions did this in two steps: create a new name for the same inode (link), then delete the old one (unlink). This had an unpleasant side effect: if something interrupted the process between the two steps, the file could be left with two names, or, worse, without a proper one.
The answer was the rename() system call, introduced in 4.2BSD in 1983 and later standardised in POSIX. rename() is atomic: the operation either happens completely or not at all, and no other program ever sees an in-between state. If a file already exists under the target name, it is replaced in a single step, so the target name never disappears, not even for an instant.
Countless programs rely on this. A text editor, a database or an installer often saves a file by first writing it to a temporary file and then putting it in place with rename(). If the power goes out mid-save, the old version stays intact, and a half-written file is never left in its place.
What if you move between two separate disks?
The inode trick only works within a single file system, because inode numbers only mean something there. If the source and destination are on different file systems (say, your internal disk and a USB stick), rename() fails with EXDEV ("cross-device link"). In that case mv quietly switches strategy: it copies the content, permissions and timestamps, then deletes the original.
That is slower and no longer atomic: if it is interrupted mid-copy, the destination may be incomplete, but the source is still there, because the delete only happens after a successful copy. It's worth knowing that the very same mv command takes an instant in one case and possibly hours in the other.
The most useful mv options
The POSIX standard only requires two options (-f and -i); the GNU and BSD versions offer many more. The descriptions below are for GNU coreutils mv; BSD/macOS differences are noted.
-i: ask before overwriting
By default mv silently overwrites the destination if it already exists. This is the command's most common trap: one typo, and an old file is gone. With -i (interactive), mv asks before every overwrite:
$ mv -i new.txt old.txt
mv: overwrite 'old.txt'? n
Many people set an alias in their .bashrc for this: alias mv='mv -i'. The only downside is that it's easy to get used to, and on another machine where it isn't set, it won't protect you.
-f: don't ask anything
-f (force) is the opposite: it never prompts, not even when the destination is write-protected and mv would otherwise ask. Useful in scripts where nobody is around to answer. If you give more than one of -i, -f and -n, the last one wins: mv -i -f won't ask.
-n: never overwrite
-n (no-clobber) simply skips any file whose destination already exists, without asking. Handy when you move a big batch of files and want to be sure nothing existing gets overwritten. Since GNU coreutils 9.3 the same thing is also available as --update=none, and the GNU documentation recommends it for scripts, because -n behaves slightly differently across platforms. On macOS it works as -n.
-u: only if newer
-u (update) only moves a file if there is no file at the destination yet, or if the source is newer than the destination file. Useful for manual syncing, when you merge the contents of two folders and don't want an older version to overwrite a newer one.
-v: tell me what you're doing
-v (verbose) prints a line for every file it moves. Invaluable with many files and in scripts, because you can see afterwards what went where:
$ mv -v *.jpg photos/
renamed 'IMG_0001.jpg' -> 'photos/IMG_0001.jpg'
renamed 'IMG_0002.jpg' -> 'photos/IMG_0002.jpg'
-b and --backup: save what you would overwrite
With -b, mv makes a backup of the destination file before overwriting it, by default with a ~ suffix (old.txt~). --backup=numbered creates numbered backups (old.txt.~1~, old.txt.~2~), and -S (--suffix) lets you pick your own suffix. This is a GNU speciality; macOS doesn't have it.
mv --backup=numbered settings.conf /etc/app/settings.conf
-t: target first
The last argument of mv is the destination. With -t (target-directory) you can put the target directory first, which comes in handy when the list of source files is produced by another program, such as find or xargs:
find . -name '*.log' -mtime +30 -exec mv -t ./old-logs/ {} +
This moves every log file older than 30 days into the old-logs directory in a single step.
-T: the destination is never a directory
-T (no-target-directory) is the reverse: it tells mv to always treat the destination as a name, never as a directory. Without it, mv project backup does two different things depending on whether backup already exists: if it doesn't, it renames project to backup; if it does, it moves it inside (backup/project). In scripts this ambiguity leads to surprising bugs; -T removes it.
--exchange: swap two files in one step
One of the newest options: since GNU coreutils 9.5, mv --exchange a b swaps the two files atomically. It relies on Linux's renameat2() system call, so it only works on systems and file systems that support it; if the destination is a directory, combine it with -T. This used to take three steps and a temporary file name.
Quick reference
| Option | What it does | On macOS too? |
|---|---|---|
-i | asks before overwriting | yes |
-f | never asks | yes |
-n | never overwrites | yes |
-u | only if the source is newer | no |
-v | prints what it moved | yes |
-b, --backup, -S | backup before overwriting | no |
-t DIR | target directory first | no |
-T | destination is always a name, not a directory | no |
--exchange | atomic swap of two files | no |
Common pitfalls and tricks
File names starting with a dash. If a file is called -f.txt, mv -f.txt new.txt takes it for an option. The fix: -- marks the end of options (mv -- -f.txt new.txt), or prefix the current directory (mv ./-f.txt new.txt).
The asterisk and hidden files. mv * target/ won't move hidden files whose names start with a dot (such as .env or .gitignore), because the shell doesn't expand * to them. That's often fine, but when you relocate a whole folder it's easy to leave something behind. In that case it's simpler to move the directory itself.
Bulk renaming. mv only knows one destination name at a time and can't rename by pattern (mv *.jpeg *.jpg doesn't do what you'd expect). A short loop does the job:
for f in *.jpeg; do mv -- "$f" "${f%.jpeg}.jpg"; done
A quick backup. In Bash, brace expansion lets you rename a file to a .bak name in one short command:
mv settings.conf{,.bak} # = mv settings.conf settings.conf.bak
There is no undo. mv doesn't put anything in a trash can, and there is no Ctrl+Z. Whatever it overwrote is gone at the file system level. For important files, use -i, -n or --backup.
mv vs cp: move or copy?
The two commands are siblings, but the point is different. cp makes a copy: afterwards two independent instances exist, and changing one leaves the other untouched. mv puts the same file somewhere else: afterwards there's still only one instance, just under a different name or in a different place. On the same disk, cp therefore costs time and space, while mv costs practically nothing.
file mv: how "moving files" became FileMv
The name FileMv wasn't born in a branding workshop but in a terminal window.
If you work as a developer, you type it dozens of times a day: mv, space, file name, space, destination, Enter. There's hardly a simpler move on a computer. The file is where you asked it to be, no questions, no confirmations. It's so routine you don't even notice it.
Then comes the moment when that same file doesn't need to go to another folder, but to someone else. A 2 GB video for a client, the wedding photos for grandma, an exported database for a colleague. And suddenly the simplicity is gone: the mail server says the attachment is too big, the cloud drive wants the recipient to sign up, and the file transfer service deletes the link after a week, just when the recipient finally has time to download it.
That raised the question: why can't sending a file be as simple as mv? One source, one destination, done. Only here the source is your computer and the destination is another person.
The idea's working title was simply "file mv": moving files, the way a Unix user would write it down (in Hungarian, fájlmozgatás). There was a small play on words in it too: in the terminal the command comes first (mv file), but in the service the file is the main character, so the order flipped. For a long time the name lived in the notes just like that, with a space. When the time came for the project to get a proper name, it turned out we couldn't find a better one: "file mv" lost its space and became FileMv.
The name still says exactly what the service does: it moves files. Anyone who knows mv gets a little wink, and anyone for whom the terminal is unfamiliar territory still gets a name that's easy to say and remember: file-em-vee.
We wanted to borrow three qualities from mv:
- It does one thing.
mvdoesn't ask you to sign up or fill in metadata, just a source and a destination. On FileMv you can upload files up to 100 MB each without an account and get a link right away. If you need more (5 GB per file, folders, passwords, sending by email), that takes a free account, but the basic step stays the same. - It doesn't ask needless questions.
mvdoesn't ask whether you're sure you want to move the file. FileMv has no mandatory recipient field, mandatory message or expiry date to set: the link doesn't expire. - The file stays the same. After
mvthe file's content is bit-for-bit what it was before. On FileMv you upload the original file, and the recipient downloads the same one.
In short
mv has been part of Unix since 1971 and still does the same job: it moves and renames. On the same disk it only rewrites the file's name, so it's instant and atomic; between two disks it copies, then deletes. By default it silently overwrites, so for important files use -i, -n or --backup, and in scripts -t, -T and -v make it more predictable. The name FileMv comes from here too: from the working title "file mv", moving files, and the service is built in the spirit of this two-letter command: one file, one destination, no needless questions.
