Why moving a file is really copy then delete
Last reviewed: September 23, 2026 · Markdown version
Inside one filesystem, moving a file is a rename: rename() “renames a file, moving it between directories if required”, and no copy of the data is made. Across two filesystems that call does not work, so the tool has to copy the file and then remove the original — and the order it does those two things in is the whole safety story.
One filesystem: nothing actually moves
The Linux manual page for rename(2) describes it as renaming a file, "moving it between directories if required", and adds that "Any other hard links to the file (as created using link(2)) are unaffected. Open file descriptors for oldpath are also unaffected." (rename(2), Linux manual page, read 23 September 2026.) What changes is the name and the directory it is listed in; the file itself is not rewritten. That is why moving a large video between two folders on the same volume can finish at once, while a move onto a different filesystem has to carry every byte.
Two filesystems: the system refuses
Cross-volume, the same call fails with a specific error, EXDEV: "oldpath and newpath are not on the same mounted filesystem. (Linux permits a filesystem to be mounted at multiple points, but rename() does not work across different mount points, even if the same filesystem is mounted on both.)"
So the move has to be assembled out of smaller operations, and even a standard Unix tool does it that way. The FreeBSD manual page for mv(1) says: "As the rename(2) call does not work across file systems, mv uses cp(1) and rm(1) to accomplish the move. The effect is equivalent to: rm -f destination_path && cp -pRP source_file destination && rm -rf source_file" (mv(1), FreeBSD manual page, read 23 September 2026). The copy comes first and the original is removed last.
Which is why the order matters
There are two ways to sequence a cross-volume move. Delete the original first and then write the copy, and an interruption — a full disk, a removed card, a phone shutting down — leaves you with nothing. Copy first, confirm that the copy is complete, and only then delete the original, and the same interruption leaves you with two copies of the file, which is an inconvenience rather than a loss.
That is the single question worth asking of anything that moves your files, and there are three more like it.
Where Adinand Auto File Sorter fits
Copy, verify, then remove the original — in that order, every time, and a failure at any step leaves the original untouched. The destination is reserved atomically before anything is written; a copy that does not verify is discarded rather than kept; and the destination is never deleted at a point where the source might already be gone.
Nothing is overwritten either: if the destination name is taken, the file arrives as name (1).ext or name (2).ext, and two files sharing a name are compared byte for byte first, because equal sizes are not evidence of anything.
Sources: the rename(2) Linux manual page and the FreeBSD mv(1) manual page, both read on 23 September 2026. What the app does comes from its own code audit.