Why moving files to another drive is slow on Windows
Moving 50 GB inside one drive takes a second; moving files to another drive takes twenty minutes. Here is what Windows actually does in each case, and why.
Written by the team building Quick File Organizer, folders that organize themselves, by your rules.
Drag a 50 GB folder from one place to another on your C: drive and it is done before you let go of the mouse. Drag the same folder to an external disk and you have time to make coffee. Moving files to another drive is a fundamentally different operation from moving them within one, even though Windows presents both as the same drag.
Understanding which one you are doing explains the wait, the risk, and a few decisions worth making about where your folders live.
Moving inside one drive rewrites an address
A drive keeps an index of what is stored where. A folder is an entry in that index, and a file's "location" is a record saying which folder it belongs to.
Moving the file between two folders on the same volume updates that record. The blocks holding the actual content are not read, not written and not relocated — they simply belong to a different folder now.
This is why the operation is instant no matter how large the file is. A 4 KB text file and a 40 GB video take the same time, because in both cases the work is one small edit to a table.
What moving files to another drive actually does
There is no shared index across two drives. The second drive has no way to refer to blocks sitting on the first, so the data has to physically exist in both places at some point.
So Windows does the only thing it can:
- Read every block from the source.
- Write every block to the destination.
- Verify the write.
- Delete the original.
That is a copy followed by a delete, wearing the word "move". The time it takes is the time to move that much data through the slower of the two drives — and over USB, through the cable as well.
Why the progress bar is so unreliable
Because file count matters more than total size, and Windows cannot know the shape of the job until it is well into it.
Every file carries fixed overhead: create the entry, write the metadata, set the timestamps, flush. On 100,000 small files that overhead is most of the work, and the throughput figure collapses even though the drive is not busy. One 10 GB video and 10 GB of small files are not remotely the same job.
This is also why the estimate leaps around: the early files may be large and fast, and the estimate is extrapolated from them right up until it hits a folder of thumbnails.
What this means in practice
Two habits are worth forming around the fact that moving files to another drive deletes the originals only at the very end:
- Copy, verify, then delete for anything irreplaceable. If the destination turns out to be faulty, you find out after the original is gone.
- An interrupted transfer leaves the source intact. Pulling the cable mid-copy is survivable. You may be left with a partial file at the destination, which should be deleted by hand.
And two about the transfer itself:
- Use robocopy for large or flaky transfers.
robocopy SOURCE DEST /MOV /Zruns in restartable mode and picks up where it left off, which a dragged folder cannot. It is built into Windows. - Do not start one on battery. The operation you least want interrupted is also the one most likely to outlast your remaining charge.
Keep destinations on the same drive as the source
This is the practical payoff, and it is worth designing around.
If you sort files automatically, put the destination folders on the same volume as the folder being watched. A rule that files a download into a folder on the same drive completes instantly and cannot be interrupted. A rule that ends up moving files to another drive turns every arriving file into a full data transfer — one that also fails whenever the external disk is unplugged.
Quick File Organizer is where this comes up in our own work: it watches a folder and routes new files by extension, with rules assigned per folder and a preview before anything moves. Keeping the targets on one volume is what makes that feel instantaneous rather than like a background transfer. The mechanics of the underlying operation are covered in how to automatically move files to another folder.
Moving files by hand is the slow version of a problem rules solve once. What a file organizer does sets out which of those jobs are worth handing over and which are not.
Common questions
Is moving faster than copying?
Within one drive, enormously — a move is an index edit and a copy duplicates every byte. Between drives they take almost exactly the same time, because the move is a copy, with a delete at the end.
Why is moving files to another drive slower than copying to it?
It should not be, and usually it is not. If a move feels slower, it is the delete pass on the source afterwards, which on a folder with very many files is not instant.
Does moving a file damage it?
No. The data is written and verified before the source is removed. The risk is not corruption but interruption, and Windows errs toward keeping the original.
Why does Windows say it is calculating for so long?
It is counting files and totalling their sizes before it starts. On a folder with a deep tree that enumeration is itself slow, and nothing visible happens while it runs.
Is it faster to zip files before moving them?
Often, yes, for many small files — one large archive avoids the per-file overhead entirely. Zipping costs time and CPU up front, so it pays off on thousands of small files and not on a handful of big ones.
Does this apply to network drives too?
Yes, and more so. A network location is always a separate volume, so every move is a copy across the network, at the speed of the connection.
Will an SSD make cross-drive moves instant?
Faster, not instant. Both drives still read and write every byte; an SSD raises the ceiling but does not remove the work. Only a same-volume move avoids it altogether.