是否有必要在连续的文件操作之间进行让步?

本文关键字：之间 操作 文件 连续 是否 | 更新日期: 2023-09-27 18:14:09

在我维护的c#代码中，我经常看到这样的模式:

File.Delete(string.Format("{0}/{1}.png", temp, ProductCode));
Thread.Sleep(20);
File.Delete(string.Format("{0}/{1}.pdf", temp, ProductCode));
Thread.Sleep(20);
File.Delete(string.Format("{0}/{1} - {2}.pdf", temp, ProductCode, ProductName));
Thread.Sleep(20);

MSDN没有以任何方式表示，如果有人可以帮助我，我想要一个明确的意见:是否有必要在这些连续删除之间产生处理器?

在这种特殊情况下，不可能有来自其他进程的锁;删除不会失败。然而，如果我在同一线程上不加暂停地执行几个删除操作，我不确定是否会有适当的队列。

是否有必要在连续的文件操作之间进行让步?

这是巫术编程。通常是受到程序员看到file. delete()并不总是实际删除文件的启发。在多任务操作系统上运行程序不可避免的副作用，这种副作用也会让其他进程打开文件。

还有一类压缩包装的恶意软件，程序员自愿安装在他们的机器上，可能会导致延迟。反恶意软件位居榜首，搜索索引器和云存储工具紧随其后。

他们使用文件共享。删除选项打开文件，尽量减少其影响。通常可以正常工作，直到您尝试在删除文件后立即重写它。这不起作用，文件处于"删除挂起"模式，你会得到一个UnauthorizedAccessException。

然后受害的程序员倾向于注意到"等待一点"有助于避免异常。给其他进程足够的时间来完成它对文件所做的一切，并关闭文件句柄。一旦最后一个句柄被关闭，文件实际上从文件系统中消失，重新创建它不会失败。

睡20毫秒完全是随意的，而且不太可能足够。除非反复尝试，否则你永远不知道要等多久。真正的问题是，这种策略只是一种非常糟糕的重新创建文件的方式。先删除，然后创建和写入文件是非常危险的。如前所述，删除工作很好，但创建它是危险的。当出现问题时，用户将没有文件的副本。完全数据丢失。从来都不是程序的理想特性:)

不要使用巫术。正确的方法是创建一个新文件，然后使用file. replace()将其与旧文件交换，然后删除旧文件。从来没有任何数据丢失，恶意软件可以做什么来搞砸这个。通过将文件移到回收站来删除文件也是一种很好的方法，只要这种情况不经常发生，filessystem . deletefile()在每个人都喜欢的命名空间中。

相关文章：