你不能这样做，因为你不应该透过 Win32 访问 WSL 的文件系统，因为 Win32 程序根本不会知道 WSL 是什么，这样做可能会损坏 WSL 的文件系统，而 WSL 也并不期待自己的文件系统被别的程序乱动。

你可以在 WSL 里面的 /mnt/C/Users/你的用户名 /Documents/project1 里面运行你喜欢的 Linux 工具，也就是说，你可以在 WSL 里面通过 Linux Subsystem 访问 Win32 控制的部分（因为 WSL 使用的 NTFS 更底层、更少抽象，不像 Win32 app 不需要知道底层文件系统，WSL 永远运行在 NTFS 上），WSL 是知道这部分文件系统通常归 Win32 使用，所以能够处理其中的变化。

除了从技术实现层面的“是否感知”来理解这个问题，你还可以通过“独立存储”这个概念来理解这个问题，算是更抽象的一种理解（从软件模型的基本假设开始）。

WSL 的实现是一个 Appx Package，它的独立存储（例如你正在访问的 %USERPROFILE%\AppData\Local\Packages\<PackageFamilyName>\LocalState 是完全属于这个 Appx Package 的，Appx Package 应当假设没有任何人修改这部分文件。换言之，即使你尝试编辑一个 UWP app 或者通过 Store 分发的 Win32 app 的这个文件夹，也会导致 undefined behavior，因为所有的 Appx Package 都是基于“我的独立存储是我自己控制的”这个假设来编写和运行的。

再类比一下的话，考虑 Word，它会存储一些设置在 AppData 文件夹里面，也会允许用户把文档保存在 Documents 里面。Word 的编写和运行是基于“用户不能乱动我的 AppData ”这个假设的，因此用户不能动它的 AppData，如果用户胡乱剪切、粘贴 AppData 里面的文件，那么 Word 可能崩溃或者恢复出厂设置，用户如果把 AppData 从一台电脑复制到另一台电脑，Word 不保证这些内容对应的效果在另一台电脑上是有效的。但是它并不假设“用户不能动自己的 Documents ”，所以你的文档保存在 Documents 里面，你可以随便移动、复制你的文档，Word 仍然可以打开移动过的、复制过的文档，你可以把文档发送到另一台电脑，那么另一台电脑的 Word 也必须可以打开收到的文件。

用 WSL 在 WSL 的 /Users/WSLUserName/Documents 里面建立文件，再用 Win32 app 去访问 %USERPROFILE%\AppData\Local\Packages\<WSLPackageFamilyName>\LocalState\rootfs\Users\WSLUserName\Documents，就相当于乱动 Word 的 AppData，WSL 不需要处理这种情况。

用 WSL 在 WSL 的 /mnt/C/Users/WindowsUserName/Documents 里面建立文件，再用 Win32 app 去访问 C:\Users\WindowsUserName\Documents 里面的文件，就相当于用户操作自己的“我的文档”里面的文件，例如把文件复制到另一台电脑上修改再复制回来，WSL 当然应该正确处理。