我在here上启动了一个线程，询问对XML文件的“并发”写入，然后将其标记为重复并引用了here，指向讨论创建锁的线程。文件与写入文件位于同一文件夹中，以作为处理情况的一种方法。
对我来说，用隐藏文件写入网络似乎不明智，尤其是当我们有能力锁定文件，而不是（似乎）没有能力锁定文件然后对它进行某些操作时。
因此，我的想法是采取不同的方法。
1：使用$file = [IO.File]::Open($path, 'Open', 'ReadWrite', 'None')锁定文件我已经确认不能两次锁定它，因此任何时候我的代码实例只能具有一个锁定。
2：将Item复制到本地临时文件夹。
3：读取该副本并根据需要添加数据。
4：保存回临时文件。
5：使用$file.Close()卸下锁
6：立即将临时文件复制-项目复制回原始文件。
风险似乎在5到6之间。另一个实例可以在第一个实例删除该锁之后但在用修订后的临时文件覆盖该文件之前设置一个锁。
使用单独的锁定文件方法是否有风险？因为这样，“锁”会一直保留到更改被保存之后？
对于我认为.NET或Powershell应该处理的事情，一切似乎都太令人讨厌了。我的意思是，具有-lock参数的StreamReaderWriter允许您拉入文件，将其弄乱并保存它，这看起来是如此基础和基础，我不敢相信它不是内置的。 / p>
答案 0 :(得分：1)
通过所有应用程序的相互协作，通常使用的一种做法是“前哨文件”或“锁定文件”。有时，仅存在文件就足够了。有时 it 变成“您锁定的文件”。
所有应用程序都必须了解您的约定并必须遵守它。这样，您就可以在不受其他合作应用程序干扰的情况下操作XML文件。
答案 1 :(得分：0)
Mike Robinson's helpful answer很好地总结了最佳实践。
关于您的问题：
风险似乎介于5和6之间。另一个实例可以在第一个实例删除该锁之后但在用修订后的临时文件覆盖该文件之前设置一个锁。
使用单独的锁定文件方法是否有风险？因为这样，“锁”会一直保留到更改被保存之后？
是的，一个独立的锁定文件，合作进程会尊重该文件，以防止出现这种竞争状况。
但是，有可能 解决此问题而没有锁定文件，尽管以花费多长时间为代价进行更新：
锁定文件使您可以“声明”文件而没有独占地锁定它，因此您可以准备更新，而其他进程仍可以读取文件。然后，您可以将独占锁定限制为使用先前准备的内容重写/替换文件的行为。
或者，您可以通过以下方式保证原子性：使用在读取，修改和保存回之前不会释放的排他锁打开文件。
换句话说：实现变得更加简单（没有锁定文件），但是更新花费了更长的时间。
但是，即使如此，您仍需要其他过程中的合作：也就是说，读者和作家都需要做好循环重试的准备。如果在正在进行的更新操作期间打开（暂时）读取文件失败。