VSCodeのターミナルをUbuntu on Windowsにしたらたまにディレクトリ名がおかしくなるぞ
プライベートの開発機はWindowsを使っているのでターミナルは基本的にGit Bashを使っていたのですが、最近Ubuntu on Windowsに変えてみました。
crontabは別途設定しないと動いてくれなかったりしますが、基本的にはWindowsの仮想環境でUbuntuが動くのでGit BashよりLinuxライクに使える部分が良いなと思ってます。
ただ、VSCodeのデフォルトターミナルに設定した際、妙な挙動をする時がありました。
動作環境
- Windows11 Home 22H2
- OS Build 22621.1105
user@host:~$ uname -a
Linux host 5.15.79.1-microsoft-standard-WSL2 #1 SMP Wed Nov 23 01:01:46 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
user@host:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.1 LTS
Release: 22.04
Codename: jammy何が起こったのか
まず前提として、Windows上のファイルをVSCodeで開こうとした際にターミナルはUbuntu on Windowsになるよう設定をしていました。
ターミナルが立ち上がった際、カレントディレクトリの表示が以下のようになる時がありました。
user@host:/mnt/wsl/docker-desktop-bind-mounts/Ubuntu/0abad672e09cc2bc63ce22143f5609596a7483fc8e31dfd25b0049e51f9ab0d8$この時に困るのはdocker composeでDockerコンテナを操作する際、通常とは異なるディレクトリと判断されてしまう点。
既にDockerコンテナが起動している状態で、別ターミナルからdocker compose up -dしようとするとconflictしたりします。
user@host:/mnt/wsl/docker-desktop-bind-mounts/Ubuntu/0abad672e09cc2bc63ce22143f5609596a7483fc8e31dfd25b0049e51f9ab0d8$ docker compose up -d
[+] Running 1/0
⠿ Network 0abad672e09cc2bc63ce22143f5609596a7483fc8e31dfd25b0049e51f9ab0d8_default Created 0.0s
⠋ Container birdseyeapi_nginx Creating 0.0s
⠋ Container birdseyeapi_selenium Creating 0.0s
⠋ Container 0abad672e09cc2bc63ce22143f5609596a7483fc8e31dfd25b0049e51f9ab0d8-mysql-1 Creating 0.0s
⠋ Container birdseyeapi_java Creating 0.0s
Error response from daemon: Conflict. The container name "/birdseyeapi_java" is already in use by container "1b05a4a364a8d3cb42c387b7741c813dd4d0a95091049e93889b59f2c6dc3f21". You have to remove (or rename) that container to be able to reuse that name.docker compose downしても、downされるのは元のディレクトリ名とは別に管理されるDockerコンテナになってしまうようです。
どう対処したか
VSCode以外のターミナルからsudo umount /mnt/wsl/docker-desktop-bind-mounts/Ubuntu/*を叩き、VSCodeのターミナルを再起動すると改善しました。（VSCodeのターミナルから叩こうとするとbusyの為、unmountできません）
ただ根本原因は掴めず…🤮
参考
https://forums.docker.com/t/docker-on-wsl2-strange-folder-name/107117
https://tako.nakano.net/blog/2022/03/check-list-for-docker-on-wsl2/