我制作了一款在Win7-PC上运行的小应用程序。它所做的就是在凌晨1点检查网络驱动器的内容(并将其与本地硬盘驱动器上的文件夹进行比较),如果存在差异,请将差异复制到此文件夹
问题是,有时它无法找到网络驱动器。
当应用程序启动时,使用启动OpenFileDialog的应用程序上的按钮找到网络驱动器,并将生成的驱动器号放入按钮旁边的文本框中。从那时起它应该自己运行。 PC永远不会关闭。
当它说无法找到网络驱动器时,我可以手动按下同一个应用程序上的按钮,在OpenFileDialog中选择驱动器(驱动器号永远不会改变),并且应用程序将在几个中运行完美无瑕天。然后问题又出现了。
问题是:为什么可以通过我的应用程序上的OpenFileDialog访问网络驱动器,但我的应用程序不能?
我的应用程序使用此函数启动复制过程(使用“Y:\”调用)以确定驱动器是否存在:
public bool fn_drive_exists(string par_string)
{
DirectoryInfo di_dir = new DirectoryInfo(par_string);
if (di_dir.Exists)
{
return true;
}
return false;
}
...有时会返回False,直到我使用OpenFileDialog“唤醒它”。
OpenFileDialog做了什么,我的应用程序没有?
答案 0 :(得分:1)
根据这个SO post,如果您使用UNC路径而不是映射网络驱动器,问题就应该消失。
答案 1 :(得分:0)
如果您的目的地有静态IP地址,我建议您使用该IP地址而不是域名进行网络驱动
答案 2 :(得分:0)
This SO post描述了与您所描述的类似的情景。
作为对该问题的回复而发布的其中一个链接使我this MSDN article提供了各种原因,说明为什么在尝试使用映射的驱动器号访问共享网络驱动器时可能会遇到错误。
微软的建议(见下文)是简单地使用UNC路径。
必须访问远程资源的服务(或在不同安全上下文中运行的任何进程)应使用通用命名约定(UNC)名称来访问资源。
为了更具体地回答您的实际问题,关于它为什么突然无法访问网络共享,我冒昧地猜测,由于空闲超时,Windows正在断开网络共享,如KB297684。当重新建立与网络共享的连接时,任何尝试访问断开连接的驱动器都会遇到一点等待,这可能是造成您问题的原因。
为了测试这个理论,尝试以相对较短的间隔(每10分钟,可能是?)将一些数据写入网络驱动器上的文件,以尝试说服 Windows驱动器仍处于活动状态
答案 3 :(得分:0)
您也可以尝试使用:
System.IO.Directory.Exists(par_string);
而不是为同一件事编写自己的方法。我希望框架方法能够“唤醒”网络驱动器。
注意:方法也适用于UNC路径(类似\\<server name or IP address>\<shared folder>
)
答案 4 :(得分:0)
像Harvey所说,使用UNC路径访问该文件夹,例如\\ server \ sharedfolder。代替\\ server使用服务器的名称。您的计算机有一个名称,服务器也是如此。如果您知道,也可以使用IP地址。您将\ sharedfolder替换为文件的路径。一些例子:
\\ AppsServer \ c $ \ Program Files(x86)
\\ FileServer1 \ d $ \ Users \ John \ My Documents
c $表示C盘是共享文件夹。如果未共享整个驱动器,则需要共享特定文件夹。您可以通过登录服务器,右键单击文件夹,然后选择“属性”来完成此操作。然后转到“共享”选项卡,选中“共享此文件夹”复选框。如果您的共享文件夹名为MyShare,则访问该文件夹的UNC路径将为
\\服务器\ MyShare中