我目前正在使用文件流将文件从一个位置复制到另一个位置。 直到现在,当我突然遇到File.open冻结正在运行的线程的问题时,这一切都按预期运行。
FileStream sourceStream = File.Open(filePath, FileMode.Open)
仅适用于1个特定文件(大小为3 GB)。有趣的是前一天它正常运行虽然这个文件所以它不能是文件大小。我检查的下一件事是,如果抛出一些我没有抓到的异常。
我把一个try / catch块整个(通常我使用调用方法来捕获异常)并且仍然具有相同的效果。
try
{
FileStream sourceStream = File.Open(filePath, FileMode.Open);
sourceStream.Close();
}
catch (Exception e)
{
Console.Write("A");
}
我还检查了如果已经访问该文件会发生什么。然后抛出异常(对其他文件进行测试,就像我说的这个特定文件一样,当我尝试打开它时,它总是挂起线程)。
该文件位于本地硬盘驱动器上,同一文件夹中的其他文件(虽然较小)不显示此问题。
由于我现在已经没有想法可能的原因,我的问题是: 这种意外行为的可能原因是什么?它们如何被广告?
编辑: 它现在再次起作用(就在我尝试使用过程监视器时,它再次开始运行)。 所以完全没有任何线索可能导致这种现象。如果有人知道这可能是什么原因,那么最好避免将来可能重复出现问题。
另外值得注意的是,在File.Open之前提出了一个问题我有一个使用块:
using (var stream = new BufferedStream(File.OpenRead(filePath), 1024 * 1024))
{
//..do calculations
}
我用它来做一些关于文件的哈希计算。这个打开文件完全没有问题(只有后来的File.Open有问题)
编辑: 我刚刚收到了来自系统管理员的信息,这些信息为这个问题带来了新的亮点: 系统的设置方式使得整个系统一次又一次地备份,而不是在知道它的操作系统的情况下。这意味着在备份文件的情况下操作系统认为它在那里并且没有人访问它,而实际上它当前正在备份(因此根据他们描述备份过程的方式访问并且无法从操作系统内访问它。 ....由于操作系统不知道备份发生,资源硬盘访问和任务管理器中都没有显示。 因此,根据该信息,可能是因为操作系统不知道正在访问的文件,它试图访问它(通过open命令)并等待并等待硬盘驱动器读头到达从未发生过的文件它实际上无法访问)。 因此,它必须遇到file.open命令没有的超时(如果我在那里准确地理解了系统管理员的话,至少我会猜到新的信息)
TNX
答案 0 :(得分:3)
有几个可能的原因:
您的防病毒软件。那个东西挂钩到OS并用自己的I / O函数替换它。当您打开文件时,它实际上可以在将控制权返回给您的应用程序之前执行病毒检查。您可能有一个错误的签名更新,迫使AV对您的3GB文件执行检查,后续更新可以解决问题。
驱动器上的坏扇区。这通常会使I / O执行得非常糟糕,但您的系统可能已将坏扇区重新定位到另一个扇区,因此性能恢复正常。您可以运行chkdsk /R
来查看是否有坏扇区。
另一个锁定文件的应用程序,但在这种情况下我宁愿期待异常。
答案 1 :(得分:1)
该问题并非源于c#或Windows系统,而是源于PC自身设置的体系结构。
在这种情况下,它的设置是要使我尝试读取的文件在没有本地PC操作系统知道的情况下是不可能的(因为它们正在备份)。
因此,操作系统认为文件是可访问的,并且C#在尝试打开文件时从操作系统收到了该答案。由于C#中的文件操作使用其Windows等效项,因此它们没有超时...。整个操作挂起/冻结,直到文件备份完成。
回想一下,我会说:卢卡斯·特热涅夫斯基(Lucas Trzesniewski)的答案应该涵盖大多数发生冻结的情况。...我自己的问题并没有得到回答,这仅仅是因为我的特殊情况最终导致了问题。
答案 2 :(得分:0)
你是否绝对确定冻结总是发生在File.Open()
?
鉴于没有例外情况,问题似乎可能处于较低水平。当您体验过它时,您尝试使用十六进制编辑器或其他工具打开文件以检查它实际上是否完全可读?这可能是访问硬盘驱动器某个区域的问题。
如果您需要只读,只写等,请尝试使用FileAccess
指定访问模式。
另请参阅this post了解BufferedStream的实际用途。
答案 3 :(得分:0)
您是否使用FileAccess&amp ;;检查File.Open()函数? FileShare值,
我认为这是一个文件锁定问题