我们有一个在 Win2K SP4 服务器上每晚运行的脚本。（我知道，我们需要升级服务器操作系统。我们计划很快这样做。）
有时，当人们在桌面上打开共享文件夹时，脚本就会失败。
因此我们使用net files和net file NNNN /close批处理命令来查找并关闭它们。这对我们很有效。
然而，截至上周，Windows 7 桌面上的一些文件夹仍处于打开状态。脚本照常“关闭”了这些文件夹，并显示The command completed successfully.每个文件夹的日志。但这些文件夹显然仍处于打开状态：脚本对这些文件夹的后续操作失败了。
当我登录 Win2K 服务器并使用“计算机管理”>“共享文件夹”>“打开文件/右键单击”>“关闭”手动关闭打开的文件夹时，这一点得到了证实。当我这样做时，打开的文件夹一开始会从列表中消失，但当我刷新列表时，这些文件夹又回到了列表中。
尤其，在 Windows 7 上的资源管理器中打开文件夹时会发生这种情况，但在 Windows XP 上打开文件夹时不会发生这种情况例如。如果在 XP 上的 Windows 资源管理器中打开了一个共享文件夹，而我从服务器端关闭了该文件夹，则该文件夹将保持关闭状态。在某些其他应用程序中打开文件时也不会发生此问题；例如，如果我在 Notepad++ 中打开了一个文件，然后在服务器上将其关闭，则该文件将保持关闭状态。
在服务器端，我在 Win2003 Server 和 Win2008 Server Standard SP2 中测试了此现象。结果是一样的：当您从服务器端关闭打开的共享文件夹时，它会立即重新出现（或者在 Win2008 的情况下永远不会消失）。但前提是它是从 Windows 7 打开的；而不是从 Win2003 Server 打开的。
所以我想知道最近是否有一些 Windows 7 更新导致资源管理器立即重新打开已被服务器关闭的文件夹？
如果是这样，我可以从服务器端做些什么来保持这些文件夹关闭直到我们的脚本运行完成？
谢谢任何帮助或建议。
答案1
我不知道我是否喜欢这个建议，但我还是会提出来。那么使用“net stop server”，然后在进程完成后使用“net start server”怎么样？由于共享服务将处于脱机状态，因此无论客户端工作站如何尝试，都无法重新连接。我不知道这会对您的企业产生什么其他副作用。打印机和其他 Windows 服务也会脱机，所以请提前注意。