各种挂载点的位置就是FHS的域。有几个选项可用于安装永久卷，例如 Windows C 驱动器。让我们通过它们来了解微软决定背后的理由。

在/media/c

这是我的第一个想法，因为/media/*我个人习惯于在我的 Linux 机器上安装永久安装的驱动器，例如内部硬盘驱动器和 SSD。

FHS 说：

此目录包含用作可移动媒体（如软盘、cdrom 和 zip 磁盘）的挂载点的子目录。

所以，根据规范，这并不是我们想要的。虽然我不确定c从 WSL 卸载在技术上是否可行，但从传统意义上讲，它肯定是不可移动的。

许多 GUI 文件浏览器也会在边栏中显示安装在那里的卷。对于 WSL，这通常不应该是一个大问题，但考虑一下还是有好处的。

优点：

• 一个非常直观的选择
• 许多文件管理器支持

缺点：

• 不完全符合规范
• 将可移动和永久媒体放在一起

在/mnt/c

这显然是微软选择的选项。但为什么？再次查看规范，我们看到：

提供此目录是为了系统管理员可以根据需要临时挂载文件系统。

虽然使用 /mnt 中的子目录作为挂载点最近很普遍，但这与直接使用 /mnt 作为临时挂载点的更古老的传统相冲突。

嗯。这也不太适合我们的用例。通常，在使用 时/mnt，挂载的是它/mnt 本身/mnt，而不是子目录——但由于这只能由管理员临时手动完成，因此管理员仍可以自行决定挂载到他们喜欢的任何位置。当然，它并不意味着要由系统自动安装。总而言之，这对微软来说似乎是一个糟糕的选择。

优点：

• ？？？

缺点：

• 绝对不符合规范
• 意味着你不能安装任何东西/mnt
• 建议它是手动安装的而不是自动安装的

在/c

这可能是一个直观而明显的选择。它反映了驱动器名称作为每个路径的第一部分的 Windows 隐喻，并且很容易输入和记忆。但是 FHS 不喜欢/.

禁止创建根文件系统的新子目录有几个原因：

• 它需要根分区上的空间，出于性能或安全原因，系统管理员可能希望该空间保持小而简单。

• 它避开了系统管理员可能为跨可安装卷分布标准文件层次结构而设置的任何规则。

如果没有非常仔细地考虑包括应用程序可移植性在内的后果，发行版不应在根层次结构中创建新目录。

优点：

• 直觉的

缺点：

• 绝对不符合规范

概括

在*nix 系统的用户中，在何处安装永久驱动器是一个长期存在的问题。不幸的是，目前似乎没有达成大量共识。我个人的看法是，微软做出了错误的决定，本来/media/c会更好，但/c也是一个有效的选择。但是，由于缺乏一致意见，它可能只是由开发人员随机选择并且从未更改过。无论如何，WSL 安装C:位置的答案/mnt/c是“它就是这样”。

有谁知道微软为什么选择挂载 WSL 目录/mnt/c而不是/c？

正如这里的另一个当前答案所证明的那样（并且非常好），这可能更像是一个意见问题而不是任何事情。由于基于意见的问题，公平地说，在这里是题外话，我将解决你（暗示的）问题的另一部分：

我在网上看到了关于如何将其更改为 的教程/c，但我担心这种更改可能会破坏某些内容。

虽然我不一定鼓励它，但我不担心它会破坏任何东西，至少在传统意义上不会。

[WSL docs]( https://learn.microsoft.com/en-us/windows/wsl/wsl-config#automount-settings )中直接提到了更改它的方法。只需sudo -e /etc/wsl.conf添加：

[automount]
root=/

退出您的 WSL 发行版，从 PowerShell 运行wsl --shutdown（或wsl --terminate <distro>）（作为普通的非管理员用户），然后重新启动。

您现在应该看到/c（以及根级别的任何其他 Windows 驱动器）。/mnt请注意， （例如）下的预先存在的挂载点/mnt/c仍然存在，但为空。您可以sudo rmdir /mnt/c（等）为每个驱动器。

我有一些相当良性的理由建议您将坐骑保持在/mnt：

• 其他人都在这样做 ;-)

  如果您遵循 WSL 指示（例如另一个 Stack 答案），他们通常会假设该位置是/mnt/c

• 一些代码可能会错误地假定/mnt/c

  一些第三方代码/mnt/c也可能假设的可能性很小。并不是说您可能会运行很多第三方 WSL 代码。

• 其他人都在这样做（redux）

  当您将来发布问题时，如果您确实将挂载点更改为/c，那么我鼓励您确保在您的问题中引用这一事实（假设您正在使用该路径）。否则，这只是希望回答的人可能需要解决的又一个细节问题。

但同样，这仅意味着保持 WSL 默认值是“阻力最小的路径”。如果您这样做，我仍然不希望有任何“破坏”。