c# - 并发文件.移动同一文件

Question

这里明确说明File.Move是原子操作:Atomicity of File.Move .

但以下代码片段导致多次移动同一文件的可见性。

有人知道这段代码有什么问题吗？

using System;
using System.Collections.Generic;
using System.IO;
using System.Threading.Tasks;

namespace FileMoveTest
{
    class Program
    {
        static void Main(string[] args)
        {
            string path = "test/" + Guid.NewGuid().ToString();

            CreateFile(path, new string('a', 10 * 1024 * 1024));

            var tasks = new List<Task>();

            for (int i = 0; i < 10; i++)
            {
                var task = Task.Factory.StartNew(() =>
                {
                    try
                    {
                        string newPath = path + "." + Guid.NewGuid();

                        File.Move(path, newPath);

                        // this line does NOT solve the issue
                        if (File.Exists(newPath))
                            Console.WriteLine(string.Format("Moved {0} -> {1}", path, newPath));
                    }
                    catch (Exception e)
                    {
                        Console.WriteLine(string.Format("  {0}: {1}", e.GetType(), e.Message));
                    }
                });

                tasks.Add(task);
            }

            Task.WaitAll(tasks.ToArray());
        }

        static void CreateFile(string path, string content)
        {
            string dir = Path.GetDirectoryName(path);

            if (!Directory.Exists(dir))
            {
                Directory.CreateDirectory(dir);
            }

            using (FileStream f = new FileStream(path, FileMode.OpenOrCreate))
            {
                using (StreamWriter w = new StreamWriter(f))
                {
                    w.Write(content);
                }
            }
        }
    }
}

矛盾的输出如下。似乎该文件已多次移动到不同位置。在磁盘上只有其中一个存在。有什么想法吗？

Moved test/eb85560d-8c13-41c1-926a-6871be030742 -> test/eb85560d-8c13-41c1-926a-6871be030742.0018d317-ed7c-4732-92ac-3bb974d29017Moved test/eb85560d-8c13-41c1-926a-6871be030742 -> test/eb85560d-8c13-41c1-926a-6871be030742.3965dc15-7ef9-4f36-bdb7-94a5939b17dbMoved test/eb85560d-8c13-41c1-926a-6871be030742 -> test/eb85560d-8c13-41c1-926a-6871be030742.fb66306a-5a13-4f26-ade2-acff3fb896beMoved test/eb85560d-8c13-41c1-926a-6871be030742 -> test/eb85560d-8c13-41c1-926a-6871be030742.c6de8827-aa46-48c1-b036-ad4bf79eb8a9System.IO.FileNotFoundException: Could not find file 'C:\file-move-test\test\eb85560d-8c13-41c1-926a-6871be030742'.System.IO.FileNotFoundException: Could not find file 'C:\file-move-test\test\eb85560d-8c13-41c1-926a-6871be030742'.System.IO.FileNotFoundException: Could not find file 'C:\file-move-test\test\eb85560d-8c13-41c1-926a-6871be030742'.System.IO.FileNotFoundException: Could not find file 'C:\file-move-test\test\eb85560d-8c13-41c1-926a-6871be030742'.System.IO.FileNotFoundException: Could not find file 'C:\file-move-test\test\eb85560d-8c13-41c1-926a-6871be030742'.System.IO.FileNotFoundException: Could not find file 'C:\file-move-test\test\eb85560d-8c13-41c1-926a-6871be030742'.

The resulting file is here:

eb85560d-8c13-41c1-926a-6871be030742.fb66306a-5a13-4f26-ade2-acff3fb896be

UPDATE. I can confirm that checking File.Exists also does NOT solve the issue - it can report that single file was really moved into several different locations.

SOLUTION. The solution I end up with is following: Prior to operations with source file create special "lock" file, if it succeeded then we can be sure that only this thread got exclusive access to the file and we are safe to do anything we want. The below is right set of parameters to create suck "lock" file.

File.Open(lockPath, FileMode.CreateNew, FileAccess.Write);

Answer 1

Does anyone know what is wrong with this code?

我想这取决于你所说的“错误”是什么意思。

您所看到的行为并非恕我直言意外，至少如果您使用的是 NTFS(其他文件系统的行为可能相似也可能不相似)。

底层操作系统 API(MoveFile() 和 MoveFileEx() 函数)的文档并不具体，但通常 API 是线程安全的，因为它们保证文件系统不会被并发操作破坏(当然，您自己的数据可能会被破坏，但它将以文件系统一致的方式完成)。

最有可能发生的是，随着移动文件操作的进行，它首先从给定目录链接中获取实际文件句柄(在 NTFS 中，您看到的所有“文件名”实际上很难链接到基础文件对象)。获得该文件句柄后，API 会为底层文件对象创建一个新文件名(即作为硬链接(hard link))，然后删除之前的硬链接(hard link)。

当然，随着这个过程的进行，在线程获得底层文件句柄和删除原始硬链接(hard link)之前之间存在一个窗口。这允许一些但不是所有其他并发移动操作看起来成功。 IE。最终，原始硬链接(hard link)不存在，进一步尝试移动它也不会成功。

毫无疑问，以上是过于简单化了。文件系统行为可能很复杂。特别是，您所说的观察结果是，当一切都说完之后，您只会得到文件的一个实例。这表明 API 也以某种方式协调各种操作，这样只有一个新创建的硬链接(hard link)存活下来，这可能是因为 API 实际上只是在检索文件对象句柄后重命名关联的硬链接(hard link)，而不是创建一个新的并删除旧的(实现细节)。

归根结底，代码的“错误”在于它有意尝试对单个文件执行并发操作。虽然文件系统本身将确保它保持一致，但您自己的代码可以确保此类操作得到协调，从而使结果可预测且可靠。