如何检查文件锁定?
有没有办法在不使用 try/catch 块的情况下检查文件是否被锁定?
目前,我知道的唯一方法就是打开文件并捕获任何 System.IO.IOException。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
有没有办法在不使用 try/catch 块的情况下检查文件是否被锁定?
目前,我知道的唯一方法就是打开文件并捕获任何 System.IO.IOException。
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(12)
我最终做的是:
What I ended up doing is:
同样的事情,但在 Powershell 中
Same thing but in Powershell
当我遇到类似的问题时,我完成了以下代码:
When I faced with a similar problem, I finished with the following code:
其他答案依赖于旧信息。 这提供了一种更好的解决方案。
很久以前,不可能可靠地获取锁定文件的进程列表,因为 Windows 根本不跟踪该信息。 支持重新启动管理器 API< /a>,该信息现已被跟踪。 重新启动管理器 API 从 Windows Vista 和 Windows Server 2008 开始可用 (重新启动管理器:运行时要求)。
我将采用文件路径并返回锁定该文件的所有进程的
List
的代码放在一起。更新
这是另一个对示例代码的讨论< /a> 了解如何使用重新启动管理器 API。
The other answers rely on old information. This one provides a better solution.
Long ago it was impossible to reliably get the list of processes locking a file because Windows simply did not track that information. To support the Restart Manager API, that information is now tracked. The Restart Manager API is available beginning with Windows Vista and Windows Server 2008 (Restart Manager: Run-time Requirements).
I put together code that takes the path of a file and returns a
List<Process>
of all processes that are locking that file.UPDATE
Here is another discussion with sample code on how to use the Restart Manager API.
您可以使用 .NET FileStream 类方法 Lock 和 Unlock,而不是使用互操作:
FileStream.Lock
http://msdn.microsoft.com/en-us /library/system.io.filestream.lock.aspx
FileStream.Unlock
http://msdn.microsoft.com/en-us /library/system.io.filestream.unlock.aspx
Instead of using interop you can use the .NET FileStream class methods Lock and Unlock:
FileStream.Lock
http://msdn.microsoft.com/en-us/library/system.io.filestream.lock.aspx
FileStream.Unlock
http://msdn.microsoft.com/en-us/library/system.io.filestream.unlock.aspx
不,不幸的是,如果你仔细想想,这些信息无论如何都是毫无价值的,因为文件可能会在下一秒被锁定(阅读:短时间跨度)。
为什么您特别需要知道文件是否被锁定? 了解这一点可能会给我们提供其他方式为您提供好的建议。
如果您的代码如下所示:
那么在这两行之间,另一个进程可以轻松锁定该文件,从而给您带来与开始时试图避免的相同问题:异常。
No, unfortunately, and if you think about it, that information would be worthless anyway since the file could become locked the very next second (read: short timespan).
Why specifically do you need to know if the file is locked anyway? Knowing that might give us some other way of giving you good advice.
If your code would look like this:
Then between the two lines, another process could easily lock the file, giving you the same problem you were trying to avoid to begin with: exceptions.
您还可以检查是否有任何进程正在使用此文件,并显示必须关闭才能继续的程序列表,就像安装程序一样。
You can also check if any process is using this file and show a list of programs you must close to continue like an installer does.
您可以通过互操作调用 LockFile您感兴趣的文件区域。这不会引发异常,如果成功,您将在文件的该部分(由您的进程持有)上获得锁定,该锁定将一直保持到您调用 UnlockFile 或您的进程终止。
You could call LockFile via interop on the region of file you are interested in. This will not throw an exception, if it succeeds you will have a lock on that portion of the file (which is held by your process), that lock will be held until you call UnlockFile or your process dies.
但是,这样您就会知道问题是暂时的,并稍后重试。 (例如,您可以编写一个线程,如果在尝试写入时遇到锁,则不断重试,直到锁消失。)
另一方面,IOException 本身不够具体,以至于锁定是 IO 的原因。失败。 可能有一些不是暂时的原因。
However, this way, you would know that the problem is temporary, and to retry later. (E.g., you could write a thread that, if encountering a lock while trying to write, keeps retrying until the lock is gone.)
The IOException, on the other hand, is not by itself specific enough that locking is the cause of the IO failure. There could be reasons that aren't temporary.
您可以先尝试自己读取或锁定文件,以查看该文件是否被锁定。
请在此处查看我的答案以获取更多信息。
You can see if the file is locked by trying to read or lock it yourself first.
Please see my answer here for more information.
DixonD 优秀答案的变体(见上)。
用法:
A variation of DixonD's excellent answer (above).
Usage:
以下是 DixonD 代码的变体,它增加了等待文件解锁的秒数,然后重试:
Here's a variation of DixonD's code that adds number of seconds to wait for file to unlock, and try again: