2009-08-21 40 views
0

我做到以下几点:的DeleteFile失败

  1. 复制的可执行文件C:\temp\x.exe

  2. System.Diagnostics.Process.Start启动可执行文件,然后等待过程中退出,同步通过拨打WaitForExitProcess对象Start返回。

  3. 删除可执行C:\temp\x.exe

在某些机器上,这个工程很大,但对他人,调用DeleteFile失败,因为该文件仍然在使用。因此,似乎一旦WaitForExit返回,它并不意味着Windows已完成EXE。

我在这里有什么选择?显而易见的是几毫秒后再次尝试DeleteFile,在一个循环中,直到删除成功或循环超时。但是有没有一种更清晰的方式来等待每个人关闭文件?

回答

1

有几个原因让你的EXE在完成执行时仍然可以被锁定。有些与你的代码有关,有些与系统有关。我认为你的代码的两个主要原因是:

如何在将exe文件复制到临时位置时关闭文件流,如果它没有明确释放,则释放时间可能会不时变化。

第二个是即使该过程完成执行并不意味着它在系统透视图中完成。

第一个可以避免第二个可以在进程列表中被监控但是你仍然有一袋可能的锁(你的程序并行执行两次,病毒扫描某个人工清理临时文件夹,光盘清理向导) 。所以我建议要么重写程序的逻辑。如果可执行文件是用c#编写的,则加载二进制文件并执行程序而不是复制文件。

如果由于某种原因每次执行时都需要复制文件,会产生一个低优先级的清理线程。让它在WaitForExit调用之后尝试清理,如果失败再次在x毫秒后再次尝试,如果再次尝试在2x之后尝试,等等。

这就是说我猜他们会(可能是非托管)API调用来查找系统级别上的文件锁。就我个人而言,我只想让系统自己找出来,尽管

+0

第一个已被排除;我使用CopyFile,没有什么花哨,并且手柄已经正确关闭。它必须是操作系统在幕后执行某些操作,在它关闭执行过程后不久。我实施了重试循环,但我对此感到不满。我想这可能是一个有趣的事情,用ProcMon等工具进一步调查。 – 2009-08-21 15:42:12