The Off-Key Bard
Technology

Why Does Moving a File Sometimes Take One Second While Copying It Takes Several Minutes?

Or: how your computer can relocate 100 gigabytes without moving 100 gigabytes. The fastest operation is the one that avoids doing the work.

Or: How Your Computer Can Relocate 100 Gigabytes Without Moving 100 Gigabytes

You have a folder with 100 gigabytes of videos, photos, and documents. You drag it to another location and it's done almost before you let go. No progress bar, no disk chatter, no waiting. Now you copy the same folder, and Windows estimates several minutes. The drive goes busy, the bar crawls, and the computer seems to be working far harder.

How can the same 100 gigabytes take under a second one way and minutes the other? Because moving a file doesn't always move the file's data. Often the computer only changes the information describing where the file belongs. The contents stay exactly where they were, and the records make it look as though they've traveled.

A File Is Not Its Contents

In File Explorer you see a tidy hierarchy: a document inside Work, inside Documents, inside your user folder. That's how humans think about it, like a filing cabinet. Storage devices don't. A drive stores data in addressable locations and has no idea what a folder is or whether something is a video or a spreadsheet. The operating system's file system supplies the organization: records describing files, directories, and which storage belongs to what. A path like C:\Users\Alex\Documents\Report.docx is translated through those records into the locations that hold the data.

So a file's name and its place in the hierarchy are one thing, and the location of its contents is another. That gap explains everything that follows.

A library catalog is a good picture. Every book sits on a physical shelf, and a catalog lists its title, subject, and shelf location. Say the library reclassifies a book from General Science to Computer Engineering. It could haul the book to a new shelf, but if the reorganization doesn't require that, it can just update the catalog. The book hasn't moved. Only the information describing how it's organized changed. A file system can do the same: a file can appear in a different folder without rewriting the blocks that hold its contents.

What a Same-Volume Move Does

The organizational information is called metadata: names, sizes, timestamps, permissions, ownership, and references to where the contents live. Each file system keeps it differently. On NTFS, the Windows default, a central structure called the Master File Table holds records describing files and directories. A directory is similarly just a structure that lists names and references to files and other directories.

Now suppose a 20 gigabyte video sits at C:\Videos\Vacation.mp4 and you move it to C:\Movies\Vacation.mp4. Both are on the same NTFS volume, so Windows can update the metadata: the entry in the old directory goes away, and the destination directory now references the file. The data extents, the storage regions holding the video, stay allocated to the same file. Nothing has to be read from the drive and rewritten. The graphical animation of a file flying between folders is a metaphor. What happened was closer to changing a label in a database.

Renaming works the same way. Changing Report-Draft.docx to Report-Final.docx doesn't rewrite a single paragraph, which is why renaming a 100 gigabyte file is about as quick as renaming a text file. The cost depends on the metadata update, not on how much data the file holds. The same goes for a folder of ten thousand files totaling 100 gigabytes: moving the folder within one volume can usually just change where the folder is attached in the hierarchy, and its children come along because they're organized beneath it. There may be extra work for permissions or application behavior, but the contents don't have to travel.

The same thinking applies on Linux and macOS. The POSIX rename call, documented in the Linux man page, atomically replaces the destination if it exists, so another process never finds it missing, and open file descriptors for the old path are unaffected. It also shows the limit: it fails with the error EXDEV when the old and new paths are on different mounted filesystems.

A path also isn't a physical address. C:\Photos\2026\October\Picture.jpg tells Windows how to reach a file, not which flash cells in your SSD hold it. The file system maps files to logical addresses, and an SSD has its own layer, a flash translation layer, mapping logical addresses to physical flash for wear leveling and cleanup. So there can be several layers between the name you see and the silicon. A same-volume move changes the top layer only. The SSD may rearrange physical data later for its own housekeeping, but that has nothing to do with which folder you chose. The same is true on a spinning hard drive: either way, an ordinary same-volume move is a metadata change.

What a Copy Has to Do

Copying has a different goal. It isn't to make the existing folder show up elsewhere; it's to create another, independent copy. The system has to create destination files, allocate space, and make the duplicate contain the data. In a conventional full copy that means reading every byte of the source and writing it to the destination. For 100 gigabytes, that's a lot of storage activity, and the speed depends on the drives, the file system, the number of files, and how the copy is implemented.

Same-drive copies still do the work. Copying a 50 gigabyte game folder to another directory on the same SSD isn't going over a network, but it still needs space for a duplicate and write operations to fill it, and the source and destination compete for the same device. That's why a same-drive copy can be dramatically slower than a same-drive move. The distinction isn't whether the data stays inside one computer. It's whether existing storage is being reused or a new copy is being made.

Small files make it worse. A 20 gigabyte video and 100,000 small files totaling 20 gigabytes are very different jobs, because each file needs its own directory entry, allocation, metadata, and open-and-close handling, and the drive spends its time on small scattered accesses instead of one long stream. That's why a folder of application files or development dependencies can take surprisingly long to copy for its size.

When "Move" Secretly Means "Copy"

The key boundary isn't one drive versus another. It's the volume. A file system volume has its own metadata and its own allocation records, and one volume can't simply adopt blocks that belong to another. Move a file from your internal SSD to an external USB drive and the destination needs its own copy of the data. Windows does what Microsoft's documentation for the move function describes: if the destination is on another volume, the move is simulated with a copy followed by a delete. In the documentation's words, with the right flag set, "the function simulates the move by using the CopyFile and DeleteFile functions." File Explorer shows a move, but the storage sees a copy and then a deletion.

The boundary is about volumes, not hardware. A single SSD can hold C: and D:, and moving between them crosses a volume boundary even though it's the same chip. Conversely, two paths that look like different drives can be on the same volume. Windows also lets a volume be mounted as a folder, so two ordinary-looking folders may actually sit on different volumes, and a move that looks local could trigger a full copy. Network shares add their own rules: a move within one server's file system may be a quick rename on the server, while a move between two shares may need the data to flow through your machine.

Drag and drop adds confusion. Explorer traditionally defaults to move when dragging within a drive and copy when dragging between drives, and modifier keys override it. But that's the interface choosing an action. Whether the system can do a metadata-only move depends on the file system's boundaries, not on your mouse gesture.

Even the progress bar can mislead. A same-volume move may finish before Windows computes a speed, while a cross-drive copy's estimate can swing as large files give way to thousands of small ones or an external drive's fast cache fills.

Copies That Aren't Copies

Modern file systems blur the line. Some support copy-on-write cloning, often called a reflink or block cloning. Instead of duplicating the data blocks, the file system creates a new logical file that initially points at the same underlying data. The Linux man page for the FICLONE operation describes making data from one file appear in another "by sharing the underlying storage," and says changes remain private to the file being written, so when one file is modified, new storage is allocated for the changed parts. Both files must be on the same filesystem, otherwise the call fails with EXDEV. Oracle's documentation for XFS reflinks says cp --reflink creates a new inode that shares the same disk blocks, is "almost instantaneous" regardless of the file's size, and uses no extra disk space at creation; space is consumed only as either file is written.

So a very fast copy doesn't mean the machine transferred data at an impossible speed. Sometimes it avoided transferring it in the first place. Don't assume every copy is a clone, though; support depends on the file system, the operating system, the tool, and the operation.

Snapshots use related ideas. A snapshot preserves a point-in-time view without immediately copying every byte, by keeping references to existing data and using copy-on-write as things change. That makes them quick to create and useful for recovery, but a snapshot on the same drive is not a backup. If the device dies, the snapshot dies with it. Fast duplication and resilience are different goals.

The same separation of names from contents shows up elsewhere. A hard link makes two directory entries refer to the same file object, so there's one set of data with two names; change it through either and you see it through both. A shortcut or symbolic link is a pointer that redirects to another path, not a copy of the target. Two items that look alike in Explorer can have very different relationships to the data underneath.

What a Fast Move Doesn't Fix

A metadata move is simple, but it has side effects that matter. Permissions can behave differently: on NTFS a moved file may keep its permissions or be affected by inheritance at the destination, while a copy creates a new object that may have different ones. The file works in one place and not in another even though its bytes are identical.

Applications are another trap. If you move a program's data folder, the move may finish instantly, and then the program stops working, because it stored an absolute path to the old location. The file system knows where the folder went. Other software may not. Open files complicate things too: Windows may refuse to move or rename a file that another program has open, not because bytes would move but because it has to respect the sharing rules of open handles.

Moving also isn't defragmentation, which really does rearrange file contents on a drive; putting a file in another folder doesn't, and on an SSD, relocating files to "speed up" a drive mostly misses the point.

Deletion runs on the same principle. Deleting a file generally updates metadata so the file is no longer reachable and its space can be reused, instead of overwriting every byte. Sending a file to the Recycle Bin on the same volume is usually another quick move into a managed folder, and restoring is quick too. That also means deletion isn't erasure: removing a directory entry doesn't prove the data is gone. Securely wiping an SSD is more complicated because of wear leveling and address translation, and is a separate subject.

Fast, but Safe

Changing metadata quickly still has to be reliable. If the power fails halfway through, the file system could be left inconsistent. Many modern file systems use journaling, which records intended metadata changes so the system can recover or finish them after an interruption. A same-volume rename can also be atomic: from the outside it appears as one indivisible change, never a half-renamed file. Software relies on that. An application can write a new version under a temporary name and rename it into place, so no other process sees a partial file.

A cross-drive move gets none of that for free. It's a copy followed by a delete, so if it's interrupted the destination can hold a partial file. Microsoft's documentation even notes a case where, if the file is copied to another volume but the original can't be deleted, the function succeeds and leaves the source intact, which means you end up with two copies. A progress bar at 60 percent doesn't mean a usable file exists. For irreplaceable photos or large backups, it's sensible to verify the copy, for instance by comparing cryptographic hashes of the source and destination, and only then delete the original. A "transfer complete" message and verified equality are related but different assurances.

The Bard's Take

Moving a file doesn't always mean moving its data. That single distinction explains one of computing's strangest everyday behaviors. When you drag a 100 gigabyte folder to another location on the same volume, the system may not transfer those gigabytes at all. It updates metadata describing where the folder belongs in the hierarchy. The data stays allocated where it was, and only the references change.

Copying is a different promise: a second, independent set of contents, which takes space and data transfer. Moving across volumes usually means copying first and deleting afterward, because the destination file system can't adopt blocks owned by another. And modern file systems add cloning, snapshots, and hard links, which separate logical files from physical storage in ever more sophisticated ways.

A file's name isn't its contents. Its path isn't its physical address. Its directory entry isn't necessarily the only reference to its data. The location File Explorer shows tells you how to reach the file, not where the bytes sit. Behind the folders and icons is a world of metadata, allocation records, and mappings that lets a computer organize enormous amounts of information efficiently.

You see a folder jump from one side of the window to the other. The operating system updates a few records. And 100 gigabytes appear to relocate in less time than a blink. The computer didn't find a miraculous way to move data faster. It found a way to do what you asked without moving the data at all.

Sources

← Back to the Desk — Technology