2

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.

2
  • 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, 2013 at 17:30
  • 1
    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, 2013 at 18:20

4 Answers 4

2

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.

2
  • What if I copy a file from one file server to another using Explorer on my local PC? Does it get copied directly or come via my PC?
    – userSteve
    May 8, 2017 at 14:10
  • @userSteve: Copied via your PC. There wouldn't be any guarantee that the two servers could even talk to each other directly.
    – Sven
    May 8, 2017 at 14:15
2

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.

-2

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.

3
  • 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. Aug 5, 2011 at 14:31
  • 2
    @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, 2011 at 14:34
  • Your right, it should be "In most cases - no" instead.
    – user48838
    Aug 5, 2011 at 19:31
-4

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).

1
  • 3
    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, 2011 at 9:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .