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

自从我开始使用Linux以来，困扰我的一件事就是它允许您更改文件名，甚至在读取文件时将其删除。一个例子是我在播放视频时不小心尝试删除它。我成功了，当我得知您可以更改文件中的几乎任何内容而不必关心当前是否在使用它们时，我感到惊讶。

每当您在Windows中打开或执行文件时，Windows都会将文件锁定在适当的位置（这是一种简化，但通常是正确的。）被该进程锁定的文件只有在该进程将其释放后才能删除。这就是为什么Windows每次必须更新自身时都需要重新启动才能生效的原因。

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

Windows默认为自动强制性文件锁定。UNIX默认使用手动的协作文件锁定。在这两种情况下，都可以覆盖默认值，但在两种情况下通常都不能。

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

而且，这是情况变得更糟的地方。除了开放用于读取或写入的功能外，C / C ++ API还没有提供指定文件用途的方法。因此，API必须假定您将执行任何合法操作。由于锁定是强制性的，一个open是允许一个冲突的操作将被拒绝，即使代码从来没有打算执行冲突的操作，但是刚刚打开该文件用于其他用途。

因此，如果代码使用C / C ++ API或使用本机API而没有特别考虑这些问题，则它们最终会阻止它们打开的每个文件的最大可能操作集，并且无法打开文件，除非它们进行了每个可能的操作打开后可以在其上执行的操作没有冲突。

在我看来，如果每个程序明智地选择并明智地处理故障情况，则Windows方法将比UNIX方法更好。但是，如果代码不必考虑这些问题，则UNIX方法会更好。不幸的是，基本的C / C ++ API无法以一种处理共享模式的方式很好地映射到Windows文件API，并且冲突打开得很好。因此，最终结果有点混乱。

这是一个非常有趣的问题，它使我思考了一个可行的答案。我希望其他人可以在这里提供备份。

我同时使用Windows和Linux，也注意到了这一点。我也是vim的用户。Vim会将一个文本文件读入“缓冲区”或RAM中，然后直到保存后才触摸实际文件。Linux通常会对所有文件执行这种操作。

以您的视频为例，它会将视频（如果可能的话）全部读取到RAM中，然后您可以获得易于访问，可搜索，可跳转的视频副本。如果文件太大，则可能会遇到问题，因为Linux可能无法读取整个视频，可能只是很大一部分。当播放机到达缓冲视频的末尾时，它将尝试再次读取文件。如果您删除了视频，那对您来说很糟糕。

Windows在某些情况下是“更安全”的操作系统，因为它不允许您这样做。它可能以与Linux相同的方式来缓冲文件，但是还增加了文件锁定功能，以防止您或其他程序更改正在处理或查看的文件。这有助于保持文件完整，并防止您或其他程序覆盖彼此的更改。