C#文件。替换以防止崩溃

是否执行原子/事务操作，以便在发生崩溃或电源故障时，目标文件不会丢失，也不会丢失部分文件（即原始文件或新文件）

如果没有，是否有其他方法可以防止这种情况

注意：这将在Windows 7或更高版本的NTFS驱动器上，据我所知，该驱动器支持事务

---

注意：我问的是如何在原子庄园中保存文件，而不关心是否有单独的进程将文件打开，如。

file.Replace不是原子的：

“File.Replace（）在内部使用对本机Windows API函数ReplaceFile（）的调用。”

---

File.Replace

在内部使用WinAPI函数

ReplaceFile

（当然是在Windows上）。然而，原子性即使在该函数中也不是一种有文档记录的行为，文档也有点模棱两可

首先，如果要保持一致性，必须使用备份文件。根据文件：

[移动文件失败时…]如果指定了lpBackupFileName，则替换文件和替换文件将保留其原始文件名。否则，替换的文件将不再存在，并且替换文件将以其原始名称存在

另一种故障模式会导致

[移动文件失败时…]替换文件仍以其原始名称存在；但是，它从要替换的文件继承了文件流和属性。要替换的文件仍然存在，但名称不同。如果指定了lpBackupFileName，则它将是替换文件的名称

这是最糟糕的文档行为-您仍然拥有两个文件，但要“复制”的文件的安全属性已更改。如果您使用的是权限有限的服务来写入文件，这可能会造成问题

最后，当删除失败时，什么也不会发生

那么，整个行动是原子的吗？尽管没有正式的文件记录，我们还是有一些建议。首先，只要您使用备份文件选项，替换操作最终是文件ID的交换（以及所有文件属性的单向更新）；这是一个在NTFS上的事务性操作，所以我的期望是这部分实际上是原子的，只要您不必担心文件属性、ACL和备用数据流

---

但是，无论是对于

File.Replace

还是

ReplaceFile

，这种行为都不是契约性的。如果您需要一种合同方式来实现跨国家操作，那么您需要使用TxF。两个主要问题是，第一，TxF仅在Vista上受支持，第二，它在实践中没有得到太多的使用，并且正在被弃用。Bummer:）微软官方推荐的替换TxF的方法记录在-中，包括使用

ReplaceFile

（在.NET中公开为

File.Replace

）。

我想答案很大程度上取决于文件是否在两个单独的物理介质上。这不是重复。链接的问题不包括该操作是否为原子操作，而是修复了尝试删除文件时出现的问题。这在实现上没有问题，而是在操作系统级别。两个文件将驻留在相同的物理和逻辑介质上