为什么我不能像在 Linux/Mac 上那样更改正在 Windows 上读取的文件的名称？

Question

自从我开始使用 Linux 以来，让我感到困惑的一件事是，它允许您在读取文件时更改文件名，甚至删除它。一个例子是我在播放视频时不小心试图删除它。我成功了，当我了解到您可以更改文件中的几乎任何内容而无需关心当前是否正在使用它时，我感到很惊讶。

Answer 1

每当您在 Windows 中打开或执行文件时，Windows 都会将文件锁定到位（这是一种简化，但通常是正确的。）被进程锁定的文件在该进程释放它之前无法删除。这就是为什么每当 Windows 必须自我更新时，您都需要重新启动才能生效。

另一方面，Linux 和 Mac OS X 等类 Unix 操作系统不会锁定文件，而是锁定底层磁盘扇区。这似乎是一个微不足道的区别，但这意味着可以删除文件系统目录中的文件记录，而不会干扰已经打开文件的任何程序。因此，您可以在文件仍在执行或以其他方式使用时删除该文件，并且只要某个进程为其打开了句柄，它就会继续存在于磁盘上，即使它在文件表中的条目已经消失。

Answer 2

Windows 默认为自动强制文件锁定。UNIX 缺省为手动协作文件锁定。在这两种情况下，默认值都可以被覆盖，但在这两种情况下，它们通常都不会。

许多旧的 Windows 代码使用 C/C++ API（类似于 的函数fopen）而不是本机 API（类似于 的函数CreateFile）。C/C++ API 使您无法指定强制锁定的工作方式，因此您将获得默认值。默认的“共享模式”倾向于禁止“冲突”操作。如果您打开文件进行写入，则假定写入会发生冲突，即使您从未真正写入该文件。重命名同上。

而且，这就是情况变得更糟的地方。除了打开读取或写入之外，C/C++ API 没有提供任何方法来指定您打算对文件做什么。因此 API 必须假设您将执行任何合法操作。由于锁定是强制性的open，允许冲突操作的an将被拒绝，即使代码从未打算执行冲突操作而只是出于其他目的打开文件。

因此，如果代码使用 C/C++ API，或者在没有特别考虑这些问题的情况下使用本机 API，他们最终将阻止他们打开的每个文件的最大可能操作集，并且无法打开文件，除非他们执行所有可能的操作一旦打开就可以执行它是没有冲突的。

在我看来，如果每个程序都明智地选择其共享模式和打开模式并明智地处理失败案例，那么 Windows 方法将比 UNIX 方法工作得更好。但是，如果代码不费心去考虑这些问题，UNIX 方法会更有效。不幸的是，基本的 C/C++ API 并不能很好地映射到 Windows 文件 API，以很好地处理共享模式和冲突打开。所以最终结果有点混乱。