4

我正在重构一些代码，有一个问题我可以使用一些评论。

原始代码将文件下载到流中。然后它将流写入临时目录中的文件，然后使用 File.Copy 覆盖生产目录中的现有文件。

首先将其写入临时目录并使用 File.Copy 与立即将流写入生产目录相比有什么好处吗？

一个原因可能是 File.Copy 比写入流更快，并减少了有人在写入文件时读取文件的机会。但这会发生吗？我还应该记住什么。我正在考虑分解临时目录。

MemoryStream stream = new MemoryStream();
....Download and valiate stream....
using (Stream sourceFileStream = stream)
{
    using (FileStream targetFileStream = new FileStream(tempPath, FileMode.CreateNew))
    {
        const int bufferSize = 8192;
        byte[] buffer = new byte[bufferSize];
        while (true)
        {
              int read = sourceFileStream.Read(buffer, 0, bufferSize);
              targetFileStream.Write(buffer, 0, read);

              if (read == 0)
                  break;
        }
    }

}
File.Copy(tempPath, destination, true);

与仅将流写入目标相反。

这只是我的代码，我会正确使用类似的东西sourceFileStream.CopyToAsync(TargetFileStream);

4

3 回答 3

6

好吧，想想当你开始下载并覆盖现有文件时会发生什么，然后由于某种原因下载被中止，你会留下一个损坏的文件。但是，首先将其下载到另一个位置并将其复制到目标目录会导致问题出现。

编辑：好的，现在看到代码。如果文件已经在 MemoryStream 中，则确实没有理由将文件写入临时位置并将其复制过来。你可以做File.WriteAllBytes(destination,stream.ToArray());

于 2013-05-02T22:28:33.343 回答
1

File.Copy简单的封装了流等的使用，完全没有区别。

于 2013-05-02T22:53:29.120 回答
1

将字节文件流组装到一个隔离的位置，并且仅在组装后将其复制到生产区域是一种更好的做法，原因如下：

  1. 假设在组装阶段出现电力短缺，当它位于诸如“temp”之类的独立文件夹中时，您只会得到部分文件，您可以稍后重新检查并忽略它。但是，如果您直接在生产中组装文件并且电力短缺发生 - 下次您打开应用程序时，您需要检查所有对您的应用程序不是“静态”的文件的完整性。

  2. 如果该文件正在生产中使用并且“正在组装”的新文件很长-您最终会让您的用户等待组装过程完成，但是当组装缓冲区的过程如您的示例中那样时-只需复制准备好的文件将为您的用户带来更短的等待时间。

  3. 假设磁盘空间已满......与＃1中的问题相同。

  4. 假设您的应用程序中的另一个进程存在内存泄漏，并且该应用程序在完成组装过程之前就被破坏了。

  5. 假设[填写您的灾难案例]...

所以，是的。最好按照您的示例进行操作，但真正的问题是该文件对您的应用程序有多重要？它只是另一个数据文件，例如“保存游戏”文件，还是如果无效会破坏您的应用程序？

于 2013-05-02T23:23:06.160 回答