WSL环境下Sublime Text权限冲突解决方案

实际上，Sublime Text 在 WSL 环境下保存文件失败，通常并非编辑器本身的问题。根本原因在于 Windows 与 Linux 权限模型之间的冲突，导致编辑器无法正常完成写入操作。

当你按下 Ctrl+S 后，控制台没有任何提示，文件的时间戳也毫无变化。90% 的情况下，这是由于写入路径位于 /mnt/c/ 挂载区。WSL 的 drvfs 挂载机制本身不支持原子重命名和权限透传，这正是冲突的核心所在。

为什么问题集中在 /mnt/c/ 目录下

WSL 将 C: 映射为 /mnt/c/，但其底层仍然是 NTFS 文件系统。Sublime 默认开启的 atomic_save 操作流程如下：先写入一个临时文件 file.tmp，然后通过 rename() 覆盖原文件。问题在于 NTFS 并不完全兼容 Linux 的 rename 机制。如果此时 OneDrive 正在进行同步、Windows Defender 正在扫描，或者资源管理器预览窗格锁定了文件，那么 rename() 操作会直接被软拦截，且不抛出异常，导致保存静默失败。

• atomic_save: true（默认设置）→ 在 /mnt/c/ 下几乎必然导致保存失败
• 即使手动执行 chmod 777 修改目录权限，NTFS 也仅是表面模拟，实际权限模型并未改变
• 如果 view.encoding() 返回 Western (Windows 1252)，UTF-8 的中文内容可能触发 Windows 层面的写入拦截
• 在终端中执行 echo test > /mnt/c/path/file.txt 若返回 “Permission denied”，说明系统级写入本身就不通，此时无需再调整 Sublime 配置

解决问题的三步有效方法

无需重装、无需 sudo，也无需与杀毒软件直接对抗，只需针对根因处理：

• 最彻底的方案：将项目文件移至 WSL 的原生路径，例如 ~/projects/。ext4 文件系统天然支持 atomic_save 和完整的 POSIX 权限，从根本上消除冲突。
• 如果必须使用 /mnt/c/：在 Sublime 的用户设置中强制关闭原子保存，添加 "atomic_save": false。但这仅是调试性对策，断电时存在数据丢失风险。
• 注意编码冲突：按下 Ctrl+Shift+P，输入 Set Encoding: UTF-8 确认设置。避免 BOM 干扰触发 Windows 层拦截，减少不必要的麻烦。

“以管理员身份运行”的陷阱

右键 Sublime 快捷方式选择“以管理员身份运行”，虽然能暂时绕过权限报错，但会带来严重后果：所有新建文件的属主将变为 root。随后使用 Git、npm、Python 脚本时，都会因 UID 不匹配而报 EACCES 错误。WSL 的权限一致性依赖于 UID/GID 映射，而非简单的提权。若需长期稳定协作，应配置 /etc/wsl.conf 中的 uid=1000 和 metadata 参数，而不是每次打开编辑器都先提权。