Question

在我维护的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没有说任何一种方式，如果有人可以提供帮助，我想要一个明确的意见：是否有必要在这些连续删除之间产生处理器？

在这种特殊情况下，不存在从其他进程锁定的可能性;删除不会失败。但是，如果我在同一个线程上发出多个删除操作而没有暂停，我不确定是否会有适当的排队。

Answer 1

这是伏都教编程。通常受到程序员的启发，看到File.Delete（）并不总是实际删除该文件。在多任务操作系统上运行程序的一个非常不可避免的副作用，也就是让其他进程打开文件的那种。

还有一类收缩包装的恶意软件，程序员自愿安装在他们的机器上，可能会导致延迟。反恶意软件位于该列表的首位，接下来是搜索索引器和云存储实用程序。

他们使用FileSharing.Delete选项打开文件以尽量减少其影响。倾向于正常工作，直到你做了一些事情，比如在删除文件后立即尝试重写文件。这不起作用，文件在＆＃34;删除等待＆＃34;模式，你得到一个UnauthorizedAccessException。

然后，受害程序员会注意到等待一段时间＆＃34;有助于避免异常。给其他进程足够的时间来完成它对文件的处理并关闭文件句柄。关闭最后一个句柄后，文件实际上会从文件系统中消失并重新创建它不会失败。

睡觉20毫秒是完全随意的，不太可能。除了反复尝试之外，你永远不会知道要等多久。 真正的问题是，这种策略只是一种非常破碎的方式来重新创建文件。首先删除，然后创建和写入文件是非常危险的。如上所述，删除工作正常，但创建它是危险的。如果出现这种情况，则会留下用户没有该文件的副本。完全数据丢失。从来没有一个非常理想的程序功能：）

不要使用伏都教。正确的方法是创建一个 new 文件，然后使用File.Replace（）将其与旧文件交换，然后删除旧文件。从来没有任何数据丢失，恶意软件无法解决这个问题。通过将文件移动到回收站来删除文件也是一种很好的方法，只要它不经常发生，FileSystem.DeleteFile（）在每个人最喜欢的命名空间中。

是否有必要在连续的文件操作之间产生？

1 个答案: