0

At the first sight the question looks similar to this one.
I have experienced an odd behavior while trying to copy a certain file from Windows Server 2008 R2 network share to Windows XP Professional client via VPN. The VPN was set up using RRAS on the server machine. I will try to provide as much informations as possible in order to make the issue more clear.

When trying to copy the compressed file sized ~2.5 MB (via Explorer or CMD, doesn't matter), the process stalls after some 20%, producing an error message after few seconds:

Cannot copy filename: The specified network name is no longer available.

If i start the command ping -t 192.168.2.1 (where the IP address specified belongs to the server) side by side with the copy command, I can clearly see that the ping command times out for few seconds as the copy process stalls. When this happens all network activities are frozen. After a few seconds, the network recovers, ping continues to run normally, however the copy process stands still before it displays the above error message.

Copying other files (I tried 4-5 files), of which some are larger and some are smaller, succeeds. Seems to me that I can copy all uncompressed files. As soon as I try to copy an archive, the process freezes. Even a 707 KB large archive can't be copied.

I can only reproduce this behavior on 2 machines, both Windows XP Professional, one is w/ SP2 and the other w/ SP3. Other XP clients don't have this problem, neither do Windows 7 clients.

If I connect to the server using Remote Desktop Connection without using VPN from either of these 2 machines (using the same user account), I can copy anything I want normally, even these "problematic" files.

Does anyone have any clue about what could possibly be going on?

2
  • What av are you running client side? Is this the same (exact version) to a working clone tor different?
    – Zapto
    Apr 14, 2012 at 19:29
  • @t1nt1n ESET NOD32 v4 AV. Just like on a working machine Apr 14, 2012 at 22:19

1 Answer 1

1

Windows networking file transfer is very prone to this type of error for large files.

I would recommend using robocopy with the /Z (copy in restartable mode) option. This will allow the client to automatically resume from the point it left off instead of constantly starting over.

The condition can be caused by network load, server load, client load, or several other things. If it's always one specific file, though, I'd consider defragmenting the server and running a chkdsk on it, if possible. You may also want to check the disk load; you might need to take action to improve performance by adding more fileservers or changing the RAID type and controller or using physically faster drives.

Many VPN systems compress data as well as encrypting it (this often improves security and definitely improves bandwidth utilization), but this adds overhead that may contribute to latency. More specifically, the compressed file probably can't be compressed much more, so the network has a lot more work to do when transferring this file as compared to transferring the same file size of uncompressed data.

1
  • I can transfer larger files without problem. Also the issue is not reproducible from other clients other than these 2. The client load cause can't be an option either. Apr 14, 2012 at 22:21

You must log in to answer this question.

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