在 Linux 的 Windows 子系统上安装带有本机扩展的 Ruby gem 时，是否有可靠的方法来避免权限被拒绝错误？

Question

我希望 WSL2 能够解决这些问题，并在接下来的 6 个月左右使这个问题过时，但与此同时，我对在我的主笔记本电脑上运行 Windows 的前沿或其他预览版本感到不舒服。

有时，当我在 WSL 中安装 Ruby gem（ bundle install或bundle install --path=vendor/bundle ）时，在安装带有本机扩展的 gem 时出现Permission denied错误。

此错误的最新版本是：

Permission denied @ rb_file_s_rename - (./.gem.20191006-12131-11th7ub/byebug, /home/thomasowens/project/vendor/bundle/ruby/2.6.0/extensions/x86_64-linux/2.6.0-static/byebug-11.0.1/byebug)

为了解决它，我只是删除/home/thomasowens/project/vendor/bundle/ruby/2.6.0/extensions/x86_64-linux/2.6.0-static/byebug-11.0.1/byebug ，重新运行 bundle 命令，然后它成功了。 有时，我需要多次执行此操作，但通常可以。

最后，我可以正确安装所有的 gem，但是在设置一个新项目时很难，而且有很多带有本机扩展的 gem。 当我引入新的 gem 或更新导致需要更新本机依赖项的 gem 时也是如此。

关于这个问题我没有发现太多，但我想知道是否有什么办法可以减轻需要多次运行bundle install才能在 WSL 下设置和运行项目的痛苦。

Answer 1

我遇到的问题可能与 Visual Studio Code 的文件监视有关。 它反映在针对 WSL- 1956和3395的两个 GitHub 问题中。 Visual Studio Code 有remote.WSL.fileWatcher.polling ，可以启用它来解决这个问题。 但是， 文档指出大型工作空间会对性能产生影响，并且可能还需要调整remote.WSL.fileWatcher.pollingInterval设置。 WSL2 将解决这些问题。

启用此标志后，我在运行 VS Code 时没有看到该错误。

---

现在 WSL2 出来了，我可以禁用这个标志并且问题没有再次出现。 看来，如果您可以升级到 WSL2，那可能是首选解决方案。 但是，对于尚未升级或无法升级的任何人，切换remote.WSL.fileWatcher.polling和remote.WSL.fileWatcher.pollingInterval应该很好。