mvMove or rename files and directories
mv renames a file or moves it to another directory. Within one filesystem it is a single, instant, atomic rename that never touches the data, which is why deploys and log rotation rely on it. Across filesystems it quietly becomes copy-then-delete.
mv [OPTION]... SOURCE DEST mv [OPTION]... SOURCE... DIRECTORYYou want to rename a file, then move several files into a directory in one command.
mvThe coreutils move/rename program.
A file's name lives in its directory; the data and metadata live in the inode. On the same filesystem mv calls the rename() system call (renameat2), which removes the name from one directory and adds it to another in a single journaled metadata operation. The inode number, data blocks, owner and timestamps stay exactly the same, so moving a 50 GB file takes a millisecond, and a process that has the file open keeps writing to it under its new name. If the destination name exists, rename replaces it atomically: anyone opening the path sees either the old file or the new one, never a half-written mix. Across filesystems (say /tmp on tmpfs to /data on ext4) rename fails with EXDEV, and mv falls back to copying the bytes into a new inode, copying metadata, and then unlinking the source. That is slow, not atomic, and changes the inode.
Inside one filesystem mv only moves a name; across filesystems it has to copy every byte and then delete the source.
You move a 4.2 GB file from your home to /srv, which lives on the same filesystem. mv asks the kernel for a rename().
-iAsk before overwriting an existing destination-nNever overwrite an existing file (silently skip)-fOverwrite without asking (the default unless -i)-vPrint what was renamed, or copied and removed-bBack up an overwritten destination as file~-uMove only if the source is newer than the destination-TTreat DEST as a file name, never as a directory to move into-t DIRMove all sources into DIR (useful with xargs/find)mv app.log app.log.1 and expecting the app to start a new app.logThe app writes through an open file descriptor to the same inode, so it keeps filling app.log.1 and no new file appears.
mv, then make the app reopen its logs: systemctl reload app (or kill -USR1); or use logrotate with copytruncateWriting a config straight to its final path: render > /etc/app/app.confReaders can see a half-written file, and a failure leaves a broken config in place.
render > /etc/app/.app.conf.tmp && mv /etc/app/.app.conf.tmp /etc/app/app.conf (temp file in the same directory)mv *.csv /archive when /archive doesn't existWith one matching file, mv renames it to a file called /archive; with several, it fails with "mv: target '/archive': No such file or directory".
mkdir -p /archive && mv -t /archive/ -- *.csv (or end the target with a slash: /archive/)Assuming mv is always instant and safe for huge filesAcross filesystems (tmpfs /tmp, another disk, an NFS mount) mv copies all the data and isn't atomic.
Check with df first; stage files on the same filesystem as the destinationTry these on a Linux machine of your own. Each task has a hint and a solution.
In ~/data, rename notes.txt to notes-old.txt and show with ls -i that the inode number didn't change.
Move the three report-*.txt files from ~/data/archive/2025 into a new directory ~/data/reports, printing each move.
Atomically replace ~/app/config/app.yaml with a version where workers is 8, without ever leaving a half-written file.
Move a file from /tmp to your home with -v. Did it say renamed or copied? Check with df whether /tmp is a separate filesystem.
mvMove or rename files and directories
mv renames a file or moves it to another directory. Within one filesystem it is a single, instant, atomic rename that never touches the data, which is why deploys and log rotation rely on it. Across filesystems it quietly becomes copy-then-delete.
mv [OPTION]... SOURCE DEST mv [OPTION]... SOURCE... DIRECTORYYou want to rename a file, then move several files into a directory in one command.
mvThe coreutils move/rename program.
A file's name lives in its directory; the data and metadata live in the inode. On the same filesystem mv calls the rename() system call (renameat2), which removes the name from one directory and adds it to another in a single journaled metadata operation. The inode number, data blocks, owner and timestamps stay exactly the same, so moving a 50 GB file takes a millisecond, and a process that has the file open keeps writing to it under its new name. If the destination name exists, rename replaces it atomically: anyone opening the path sees either the old file or the new one, never a half-written mix. Across filesystems (say /tmp on tmpfs to /data on ext4) rename fails with EXDEV, and mv falls back to copying the bytes into a new inode, copying metadata, and then unlinking the source. That is slow, not atomic, and changes the inode.
Inside one filesystem mv only moves a name; across filesystems it has to copy every byte and then delete the source.
You move a 4.2 GB file from your home to /srv, which lives on the same filesystem. mv asks the kernel for a rename().
-iAsk before overwriting an existing destination-nNever overwrite an existing file (silently skip)-fOverwrite without asking (the default unless -i)-vPrint what was renamed, or copied and removed-bBack up an overwritten destination as file~-uMove only if the source is newer than the destination-TTreat DEST as a file name, never as a directory to move into-t DIRMove all sources into DIR (useful with xargs/find)mv app.log app.log.1 and expecting the app to start a new app.logThe app writes through an open file descriptor to the same inode, so it keeps filling app.log.1 and no new file appears.
mv, then make the app reopen its logs: systemctl reload app (or kill -USR1); or use logrotate with copytruncateWriting a config straight to its final path: render > /etc/app/app.confReaders can see a half-written file, and a failure leaves a broken config in place.
render > /etc/app/.app.conf.tmp && mv /etc/app/.app.conf.tmp /etc/app/app.conf (temp file in the same directory)mv *.csv /archive when /archive doesn't existWith one matching file, mv renames it to a file called /archive; with several, it fails with "mv: target '/archive': No such file or directory".
mkdir -p /archive && mv -t /archive/ -- *.csv (or end the target with a slash: /archive/)Assuming mv is always instant and safe for huge filesAcross filesystems (tmpfs /tmp, another disk, an NFS mount) mv copies all the data and isn't atomic.
Check with df first; stage files on the same filesystem as the destinationTry these on a Linux machine of your own. Each task has a hint and a solution.
In ~/data, rename notes.txt to notes-old.txt and show with ls -i that the inode number didn't change.
Move the three report-*.txt files from ~/data/archive/2025 into a new directory ~/data/reports, printing each move.
Atomically replace ~/app/config/app.yaml with a version where workers is 8, without ever leaving a half-written file.
Move a file from /tmp to your home with -v. Did it say renamed or copied? Check with df whether /tmp is a separate filesystem.