Puncte:1

Nu se poate deschide codul de studio vizual când în interiorul unității montate sshfs UBUNTU WSL

drapel ru

Am avut probleme cu deschiderea codului de studio vizual.

Scenariul este că am un sistem de fișiere server montat în computerul meu local (UBUNTU WSL) folosind SSHFS.

În cazuri normale, pot deschide fișierul folosind codul Visual Studio folosind comanda codul <nume fișier>.
Cu toate acestea, când mă aflu în directorul sistemului de fișiere al serverului și încerc să folosesc această comandă, primesc eroarea

/mnt/c/Users/kurti/AppData/Local/Programs/Microsoft VS Code/Code.exe: Argument nevalid

În mod surprinzător, pot folosi gedit în același mod, fără nicio problemă, de ex. gedit <nume fișier>.

Apoi, ceea ce este ciudat este că pot folosi codul pentru a deschide un fișier/director în sistemul de fișiere server atunci când sunt în orice folder din sistemul meu local de fișiere. Cu aceasta pot deschide cu ușurință fișierul server folosind cod </full/path/to/file>.

Este aceasta o posibilă eroare în codul studioului vizual sau o problemă cu sistemul meu?

Editați | ×: Am creat o nouă lucrare în jurul funcției/comenzii care este
numele comenzii: vcode

#!/bin/bash
fpath=$(realpath $1)
(cd $HOME; cod fpath)

Actualizați: Am raportat-o ​​în pagina Github WSL ca o problemă https://github.com/microsoft/WSL/issues/7890

Mai multe detalii specifice, după cum urmează

Pași repo

În terminalul WSL,

  1. Montați un sistem de fișiere server folosind sshfs (în cazul meu este un supercomputer universitar)
    sshfs -C <nume_și_ip_server> <locație_montare>
    mount_location desemnat este un director gol numit smith_server cu cale /home/k/smith_server/
  2. Accesați directorul cd /home/k/smith_server
  3. Deschideți directorul în codul Visual Studio cod .

Comportament asteptat

Comportamentul așteptat este că Visual Studio va deschide directorul/fișierul indiferent de directorul de lucru curent.

Comportamentul real

Comportamentul real este că atunci când directorul de lucru curent se află în sistemul de fișiere server montat, lansarea comenzii cod . sau codul <nume fișier> va avea ca rezultat cod de eroare.

/mnt/c/Users/kurti/AppData/Local/Programs/Microsoft VS Code/Code.exe: Argument nevalid

Câteva exemple care funcționează,

  1. Când directorul de lucru nu face parte din sistemul de fișiere montat pe server, cod . sau cod <fișier> Merge bine.
  2. Când directorul de lucru nu face parte din sistemul de fișiere server montat, folosind codul către o cale completă a unui fișier/director din sistemul de fișiere server, de ex. codul /home/k/smith_server poate deschide cu succes fișierul/directorul fără probleme.
  3. Când directorul de lucru se află în sistemul de fișiere server montat, gedit <fișier> Merge bine
  4. Când directorul de lucru se află în sistemul de fișiere server montat, cod $HOME primește și o eroare.

Concluzia mea este că există probleme la invocarea comenzii de cod în interiorul sistemului de fișiere server montat. În plus, acest lucru nu se întâmplă atunci când a fost folosit gedit. Cu toate acestea, când se află în afara sistemului de fișiere server montat, fișierul cod comanda poate fi invocată și, de asemenea, poate accesa sistemul de fișiere montat folosind o cale completă. Poate că se întâmplă ceva la urmărirea fișierului Code.exe. Software-ul bazat pe Linux, cum ar fi gedit, nu este afectat, dar poate că software-ul bazat pe Windows, cum ar fi Code.exe, care tocmai sunt interfațate, este afectat?

cocomac avatar
drapel cn
Aceasta ar putea fi o eroare cu modul în care funcționează VS Code în WSL. Vă sugerez [depunerea unei probleme GitHub](https://github.com/microsoft/WSL/issues/new?assignees=&labels=&template=Bug_Report.yaml) pentru a raporta acest lucru.
NotTheDr01ds avatar
drapel vn
Voi încerca să încerc asta pe sistemul meu mai târziu astăzi. Mă bucur să văd că ai măcar o soluție.
drapel ru
@cocomac Mulțumesc pentru sugestie. Am trimis un raport pe github.
drapel ru
@NotTheDr01ds Mulțumesc, puteți vedea pașii mai specifici în actualizare sau în problema pe care am trimis-o în github
Puncte:2
drapel vn

Am reușit să reproduc asta destul de ușor.

Soluţie:

  • Demontați suportul de siguranță existent:

    fusermount -u /home/k/smith_server
    
  • Editați | × /etc/fuse.conf ca root:

    sudo -e /etc/fuse.conf
    
  • Anulați comentariul user_allow_other opțiune

  • Remontați cu allow_root opțiune:

    sshfs -o allow_root [utilizator@]<server_la distanță>:/cale /home/k/server_smith
    

Mai multe detalii:

Rețineți că aceasta nu este doar o problemă cu sshfs. Te-ai întâlni când lansezi VSCode din interior orice siguranța-punct de montare bazat.

Sincer nu sunt destul de sigur de cauza principală aici, dar...

Veți observa că, fără soluția de mai sus, dacă încercați să navigați \wsl$\Ubuntu\home\k\smith_server\, nu veți putea intra în acel director. Veți avea acces la directorul dvs. de acasă, dar nu veți putea accesa smith_server.

Asta îmi spune că, deși Windows/WSL impune permisiuni pentru ta utilizator când navighează (în mod implicit, cu excepția cazului în care înlocuiți acest lucru în /etc/wsl.conf), încă pare să facă așa ca rădăcină in fundal.

Deci, odată ce ne dăm seama, nu este surprinzător că VSCode nu poate face față lansării dintr-un director care, pentru el, nu există.

Acest lucrări când îl lansezi de la $HOME deoarece VSCode se inițializează, apoi trece la extensia „Remote - WSL”, care comunică cu serverul VSCode care a fost instalat în instanța dvs. WSL (în ~/.vscode-server). Odată ce se întâmplă asta, accesează sistemul de fișiere montat pe siguranțe ca ta utilizator și totul este fericit.

Pe siguranța de om:

Niciun alt utilizator (inclusiv root) nu poate accesa conținutul sistemului de fișiere montat.

Dar, există opțiunea de a înlocui acest lucru cu oricare -o permit_altul sau -o allow_root. Și pentru a activa oricare dintre acestea, cele menționate mai sus /etc/fuse.conf opțiunea trebuie setată corespunzător.

Apoi, VSCode are acces adecvat la director la lansare.

Veți vedea, de asemenea, că acum puteți naviga, prin Windows, către \wsl$\Ubuntu\home\k\smith_server\.

drapel ru
Vă mulțumesc foarte mult pentru efort. Chiar a ajutat!

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.