Windows 的一个烦恼/特点是,一旦打开文件,就无法对文件目录条目本身执行任何操作。即,您无法在文件打开时将其移动到其他位置等。这对于确保某些操作不会出错并具有一定的可预测性很有用。
但是,许多 UNIX 工具将文件目录条目与 i 节点条目分离,并允许您移动/删除/重命名文件,而指向旧名称的现有文件句柄仍然有效。我想知道 WSL 的实现是否也具有相同的属性?
答案1
Windows 和 Linux 的工作方式非常相似 - 两者都允许重命名打开的文件,没有任何问题。文件的内容仍然由锁定过程独占锁定,即使它可能不再有名称。
但是 Linux 允许删除打开的文件,而 Windows 不允许。这是 Windows 开发人员的设计决定,因为底层文件系统结构允许这样做。
关于打开和创建文件,Windows API 有一个参数,用于定义允许其他进程的访问类型。默认情况下,创建文件会为创建进程提供独占访问权限,而打开现有文件则不会提供独占访问权限。但是,这些默认值很容易被函数的可选参数覆盖。
WSL 系统调用最终会映射到 Windows 函数调用,因此它们遵循相同的规则(取决于映射的编程方式)。WSL 能做到的,Windows API 都能做到,因为最终是 Windows API 完成这项工作,而且(在最常见的情况下)操作的是相同的 NTFS 文件表。
答案2
我不太确定如何重现/测试您所想到的场景,但答案可能会在 WSL1 和 WSL2 之间有所不同,并且存储在 WSL“中”的文件和 Windows 驱动器上的文件之间也会有所不同。
WSL1:
WSL2:
WSL 中的文件:
WSL2 会创建一个虚拟 SDD(Hyper-V
.vhdx
文件),其格式为 ext4 文件系统。作为虚拟驱动器,里面WSL2,所有文件访问都将通过 Linux 内核进行。VHD 在 Windows 中始终保持打开状态,但 WSL2 内部的虚拟读/写/删除操作将是自主的。从 Windows 访问 WSL 文件时,9P使用网络文件系统。使用 9P 访问文件时可能会使用附加锁定。
Windows 驱动器上的文件:
WSL2 还使用 9P 从 WSL2 实例内部访问 Windows 驱动器上的文件。同样,在这种情况下可能会使用 NTFS 限制和 9P 锁定的组合。