Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am accessing a shared folder on another machine using Windows Explorer. I find that moving a large file in that folder into a sub-folder takes a very long time. Is the file actually being copied to the new location and then deleted from the old one? Or is there another reason why it takes so long?

Note: The same operation on a local folder takes a fraction of a second since a new copy of the file is not created at all. Only the directory entries are modified.

share|improve this question
Sorry, more questions! When you move the file does the header info get moved to your local PC and then copied back?? Is that why it takes longer. Ditto if you copy from a remote m/c to the same remote m/c does the data come down the n/w and then go back up or is the n/w more intelligent and just copy the data locally (on the remote m/c)? (I Hope so!) – user182915 Jul 24 '13 at 17:30
Dave - clean that up and post it as a new question. It doesn't belong in a comment on an existing (old) question. – mfinni Jul 24 '13 at 18:20

When you use a CIFS share, moving a file inside the share should act similar to the local case, except there is something like DFS involved, where the file actually has to be copied on the server from one location to another.

DFS means that you see a single directory tree that could consist of shares on totally different servers. Something similar would be the case if different disks are mounted into a common tree on a Samba server and you move a file from one mount point to another.

share|improve this answer

A file move on a remote share is exactly the same as a local one: Explorer simply instructs the server to move the files/folders into their new destination. It can also be thought of as a full path rename. There's no need to copy the files to your local system and back out.

One of the biggest causes of any slowdown is something on your local system holding the file open: Virus scanners, shell extensions (e.g. compression utilities checking .exe files for SFX stubs, image/movie thumbnail generation, getting title/author information from Word Documents, scanning music/movies for tags, etc.), and so on. Explorer now has to wait for everything to close their open handles on the file before it can finish the file operation, and since many of the things I mentioned involve random small block I/O, SMB latency turns into a much bigger problem than it is on local disks. It's even worse if you're doing this over a wireless connection.

For an example of how fast it can be, try doing the move from a Command Prompt without Explorer open in your source folder. The operation will be very quick.

share|improve this answer

In most cases - yes, it is being copied across the network first and then deleted from the source when the copy is completed successfully. You can verify this action by disrupting the "move" which typically results in the source being intact and an incomplete copy of the target.

share|improve this answer
I've often found files littered in directories when doing network transfers and having them interrupted by something, so I've always suspected some cache-copying behavior from Windows during remote file operations. – Bart Silverstrim Aug 5 '11 at 14:31
@user48838: This is nonsense. Moving a file inside a network share (without the special cases noted in my answer) just moves it, it doesn't copies it to the local machine and then back to the new location. If this is indeed is happening on your machine, something is wrong. But I guess you misread the question and are thinking about a move from a local folder to a remote one. – Sven Aug 5 '11 at 14:34
Your right, it should be "In most cases - no" instead. – user48838 Aug 5 '11 at 19:31

Maybe I'm overly cautious, but I would never advise moving files across a network. Instead, I copy and paste, validate that the sizes match exactly, and then go back and delete them. I just don't trust the OS to keep up with it well enough (no matter the OS).

share|improve this answer
You can't be sure the contents match just by checking the file size, so you need to compute the SHA2 hashes of each copied file. But in all seriousness, if you don't trust the OS with the basic task of moving files, you shouldn't be using a computer. – Nic Nov 29 '11 at 9:52

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.