乍看之下，这个问题看起来和这个相似。
尝试从Windows Server 2008 R2networking共享中将某个文件通过VPN复制到Windows XP Professional客户端时，我遇到了一个奇怪的现象。 VPN是在服务器机器上使用RRAS设置的。 我会尽量提供尽可能多的信息，以使问题更清楚。
当试图复制约2.5 MB的压缩文件（通过资源pipe理器或CMD，无所谓）时，进程停止了大约20％，几秒后产生一个错误消息：
无法复制文件名 ：指定的networking名称不再可用。
如果我用ping -t 192.168.2.1命令ping -t 192.168.2.1 （其中指定的IP地址属于服务器）并行命令，我可以清楚地看到，ping命令在拷贝进程停止时超时了几秒钟。 发生这种情况时，所有networking活动都被冻结 几秒钟后，networking恢复，ping继续正常运行，但复制过程在显示上述错误消息之前仍然保持不变。
复制其他文件（我尝试4-5个文件），其中一些更大，一些更小，成功。 在我看来，我可以复制所有未压缩的文件。 只要我试图复制一个档案，该过程冻结。 即使是707 KB的大档案也不能被复制。
我只能在2台机器上重现这种行为，这两台机器都是Windows XP Professional，一台是w / SP2，另一台是w / SP3。 其他XP客户端没有这个问题，Windows 7客户端也没有。
如果我使用远程桌面连接连接到服务器，而不使用这两台计算机（使用相同的用户帐户）中的任何一台VPN，我可以正常复制任何我想要的东西，甚至是这些“有问题”的文件。
有没有人有任何线索可能会发生什么？
Windowsnetworking文件传输非常容易出现这种types的大文件错误。
我build议使用/ Z（在可重启模式下复制）选项使用robocopy。 这将允许客户从停止的地方自动恢复，而不是经常重新开始。
这种情况可能是由networking负载，服务器负载，客户端负载或其他一些事情引起的。 如果它总是一个特定的文件，但是，如果可能的话，我会考虑对服务器进行碎片整理并在其上运行chkdsk。 你也可能想检查磁盘的负载; 您可能需要采取措施来提高性能，方法是添加更多的文件服务器或更改RAIDtypes和控制器或使用物理更快的驱动器。
许多VPN系统压缩数据并对其进行encryption（这通常会提高安全性，并明显提高带宽利用率），但是这增加了可能导致延迟的开销。 更具体地说，压缩文件可能无法被压缩得太多，所以与传输相同文件大小的未压缩数据相比，networking在传输该文件时有更多的工作要做。