Why moving a file is really copy then delete
Last reviewed: September 19, 2026 · Markdown version
Inside one filesystem, moving a file is a rename: rename() “renames a file, moving it between directories if required”, and the data itself never goes anywhere. 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 manual page for rename(2) describes it as renaming a file, "moving it between directories if required". What changes is the directory entry; the bytes stay exactly where they were on the storage. That is why moving a large video between two folders on the same volume finishes at once, and moving it to an SD card does not.
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 the most standard tool there is does it that way. The 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", and spells the sequence out — "the effect is equivalent to: rm -f destination_path && cp -pRP source_file destination && rm -rf source_file".
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) manual page and the mv(1) manual page, both read on 16 September 2026. What the app does comes from its own code audit.