S'il est désormais facile d'utiliser un terminal Linux depuis Windows 10, l'interaction entre les deux systèmes était en partie incomplète. L'édition May 2019 de l'OS de Microsoft améliorera les choses.
La nouvelle évolution de Windows 10, May 2019 (ex-19H1), arrive. Si elle apporte de nombreuses nouveautés, l'une d'elles était particulièrement attendue des développeurs : un meilleur accès aux fichiers du sous-système Linux (WSL).
Pour rappel, cette fonctionnalité permet de disposer d'un terminal tel qu'on l'obtiendrait sous Debian, Kali, OpenSUSE ou Ubuntu, avec des performances presque natives, la virtualisation n'intervenant pas. De quoi concilier le meilleur des deux mondes sans effort ni dual boot.
Un dispositif assez complet, mais pas sans défauts. Ainsi, outre l'absence d'interface graphique, WSL ne permet pas d'accéder facilement aux fichiers de ses distributions depuis l'Explorateur de Windows (par exemple). Surtout, l'accès ne peut se faire qu'en lecture seule, au risque de corrompre les données. Heureusement, une solution a été trouvée.
Microsoft intègre un serveur 9P dans Windows 10
La technologie utilisée n'a rien de bien nouveau : Windows va exploiter le protocole d'accès aux fichiers et périphériques de Plan 9, un système d'exploitation des Bell Labs sorti dans les années 90 : 9P.
Il est utilisé sous forme d'un serveur intégré aux instances WSL, permettant l'accès aux données depuis un pilote et un service Windows faisant office de client. La communication entre ces deux éléments se fait via des sockets Unix (AF_UNIX), introduits dans l'April 2018 Update de Windows 10.
WSL et les distributions installées sont donc vues désormais comme des éléments du réseau auquel on peut accéder via un chemin UNC (Universal Naming Convention) :
\\wsl$\
\\wsl$\nom_de_la_distribution
L'accès sera ainsi identique à celui d'une ressource du réseau local, même si la racine de WSL n'est pas affichée dans la section Réseau de l'Explorateur de fichiers. On peut néanmoins monter chaque élément comme un lecteur réseau ou le placer en raccourci dans l'accès rapide. Il y a toutefois d'autres subtilités (et astuces) à connaitre.
Plus d'options pour WSL
Tout d'abord, l'application wsl.exe dispose désormais d'options supplémentaires permettant de lister les distributions installées et/ou lancées, mais aussi de les importer/exporter d'une machine à l'autre. On peut les « terminer » (ce qui revient à les fermer), les désenregistrer du système ou encore décider laquelle est utilisée par défaut.
Pour celles installées avant Windows 10 May 2019, une mise à jour sera possible avec le nouveau système de fichiers.
L'aide de l'application wsl.exe dans Windows 10 April 2018 et May 2019
Un accès depuis l'Explorateur ou PowerShell
Microsoft prévient qu'il ne faut pas accéder aux fichiers d'une distribution WSL via le répertoire AppData de l'utilisateur, ce qui reviendrait à outrepasser le serveur 9P, donc potentiellement de les endommager.
Ressource réseau oblige, l'accès ne peut pas se faire via cd dans l'Invite de commandes classique (cmd.exe). On peut par contre utiliser le chemin d'une distribution comme source ou destination, pour ouvrir ou copier un fichier par exemple. PowerShell n'est pas concerné par cette limitation, mais ne peut accéder à la racine :
On regrette au passage que le nom des distributions installées ne profite pas (encore ?) de l'auto-complétion via la touche Tabulation. De fait, passer par l'Explorateur sera souvent la solution la plus simple. Notez qu'il est possible de l'ouvrir dans le dossier courant d'un terminal WSL avec la commande suivante :
explorer.exe .
Dans la version actuelle de Windows 10, elle ouvre le répertoire System32.
Une évolution bienvenue, à compléter
Au final, l'ensemble s'avère pratique, même s'il faut encore composer avec des limitations pouvant demander une révision des habitudes. Mais l'intégration du serveur 9P apparaît comme un bon compromis.
Depuis l'annonce de cette fonctionnalité, certains points ont d'ailleurs été renforcés. Il était par exemple au départ impossible d'accéder aux fichiers d'une distribution WSL tant que son terminal n'avait pas été ouvert une première fois, une action mettant en route le serveur. Ce n'est désormais plus nécessaire : chercher à accéder aux fichiers suffit à son lancement.
On apprécierait néanmoins que d'autres points soient traités d'ici la publication de la mise à jour May 2019, comme l'ajout automatique d'un raccourci vers la racine WSL dans l'Accès rapide lorsqu'au moins une distribution est installée.
Microsoft incite en tous cas les utilisateurs à faire part de leurs retours via GitHub ou directement via Twitter.
Commentaires (43)
#1
“L’édition May 2019 de l’OS de Microsoft améliorere les choses.” = petite coquille dans le chapo 
" />
#2
Oui corrigé juste après la publication, fallait juste que le cache soit à jour ;)
#3
Pour le sous-titre j’aurai écrit “May encore imparfait”.
Maintenant je vais lire l’article
#4
Mieux : “Theresa ne fait plus le pingouin” 
" />
#5
Ohh, j’ai eu du mal à suivre. Mais très bien trouvé
" />
#6
Est-ce qu’on pourra par exemple installer un serveur web dans la partie “Linux” et monter les fichiers dans un IDE installé sur Windows ?
En gros, en tant que développeur WEB, me passer d’une machine virtuelle dédiée.
#7
Je trouve que ça devient une usine à gaz WSL.
#8
En tant que dev web la question est : tu fais quoi sur Windows ?
" />
#9
Certaines sociétés ne t’autorisent pas autre chose qu’un windows, avec une pléthore de VM installées dessus. Le WSL est une bouffée d’air frais pour nous :)
+1 pour l’ide sur le partage WSL !
#10
Oui comme dit dans l’article sur WSL, on peut installer un serveur web (il faut le démarrer manuellement après l’installation par contre). Et donc accéder à ses fichiers depuis WSL$ dans Windows 10 May 2019. Attention quand même à disposer des bons droits (utilisateur courant).
On peut aussi ouvrir un fichier du WSL dans une application directement depuis le terminal WSL genre :
notepad.exe fichier.txt
#11
Ça va pouvoir accélérer les temps d’accès aux fichiers avec Docker ?
#12
Ma question est peut être débile, mais pourquoi microsoft n’intègre pas en natif les systèmes de partition linux (par définition libre) et inversement pourquoi microsoft ne rend pas libre le NTFS ?
#13
J’ai hâte d’installer wine
" />
#14
+1000
C’est tellement énervant cette non compatibilité. De même que Windows qui me demande toujours de formater ma clé car il ne comprend pas les systèmes de fichier Linux :(
#15
Alors faut changer de boîte ou de DSI
" /> 
" />
#16
En attendant que ça bouge :
https://www.paragon-software.com/home/linuxfs-windows/
#17
Est-ce que le sous système Linux fonctionne sous Wine ?
" />
#18
#19
Perso, je suis pas fan d’un Windows qui communique directement avec mon Linux (si j’ai un double boot). Juste pour une histoire de sécurité.
#20
Sous ce nouveau Windows, pour accéder à nfs il faut passer par l’install d’un wsl ?
#21
#22
Il y a un client NFS dans Windows 10 si c’est la question (mais la fonctionnalité est à activer manuellement)
#23
Merci je connaissais pas !
#24
#25
Notre IDE est émulé (via un serveur X11) dans notre WSL. Et la stack LAMP dans WSL aussi.
#26
Ils ne maîtrisent déjà pas leur propre OS et leurs propres mises à jour, alors ça rime à quoi ?
#27
je suis pas d’accord mais c’est trop marrant pour être ignoré
#28
Merci pour vos réponses :)
#29
Docker le fait, il faut juste lui spécifier un volume persistant contenant ton site, et/ou bdd).
bonus, tu peut tout filer a qui tu veux pour qu’il puisse tester tes sites dans les memes condition
#30
Je suis utilisateur du sous système Linux depuis plus d’un an maintenant, et c’est un vrai bonheur.
Le plus simple, pour éditer les fichiers:
Le sous système peut les lire sans problème, et ils sont éditables via un IDE sous windows.
Au boulot et en perso, je ne passe plus que par ça pour du dev en local.
La seule limitation, c’est qu’il n’est pas possible de changer les permissions (en 0755 par exemple) pour rendre un fichier exécutable sur un véritable linux (le sous système voit les fichiers en 0777 quelque soient les perms réelles)
Et le seul point noir du sous système Linux, c’est la lenteur du filesystem pour manipuler les fichiers Windows - quelque chose comme 5 fois plus lent, voir plus dans certains cas)
#31
Tout comme les dinosaures préhistoire partouzeur de droite, je trouve tout ceci un peu contre nature et bâtard. Mais bon ça rend heureux des gens, c’est bien.
#32
Si je pouvais me débarrasser de Windows pour développer, ça serait évidemment ce que je ferais mais je n’ai pas trop le choix. Ma boite utilise un VPN propriétaire merdique dont la version Linux est boiteuse.
#33
Je te taquinais ;p
Je me doute qu’il y des impératifs liés au SI. Comme dans beaucoup d’entreprises d’une certaine envergure.
#34
#35
Pas de soucis ^^
#36
Il avait pourtant mis les smilies qui vont bien pour signaler que son propos est pas sérieux.
" />
#37
#38
#39
Rien ne t’empêche de créer un pilote ext4.
#40
Bah si : il n’en a pas la compétence.
#41
#42
Perso
j’ai une VM Kali qui route sur chacun de mes ordinateurs sous Windows 10 pour
avoir accès facilement aux outils en ligne de commande comme dig, MTR, nmap,
fierce….
La
première chose que j’essaie sous WLS est ping….. ça ne fonctionne pas…. la
deuxième, nmap….. ça ne fonctionne pas non plus…. et pas plus pour
MTR.
La
nouvelle mouture sous 1903, est-ce que ça va fonctionner ?
#43
Sa question n’est pas débile (loin de là).
" /> (pourtant il y a des droits plus ou moins comparable sur Windows ?)
Mais sur le même sujet, je ne sais pas si la mienne l’est ?
Pourquoi cela semble si compliqué d’accéder aux fichiers WSL (en tout cas en écriture) alors qu’il n’y a pas de limitation de ce genre avec Wine ?
Normalement WSL n’a pas besoin de gérer un FS Linux.
Pour moi Wine intercepte les appels système de lectures ou écritures de fichiers pour le FS Windows (NTFS, FAT ou autre, peu importe) et les traduits en appels système de lectures ou écritures vers le FS Linux via le kernel Linux (c’est le kernel qui va vraiment gérer que le FS est un ext4, btrfs, voir même un NTFS. Il y a très longtemps j’utilisais Wine pour des soft sur une partition NTFS partagée avec un Windows multi-boot). Je ne pense pas que pour cet usage Wine ait besoin de savoir écrire sur du ext4, il à juste besoin de traduire des appels systèmes vers d’autres appels systèmes.
Et donc pour moi WSL devrait faire la même chose. Mais dans l’autre sens, appel système lecture/écriture de Linux traduit en appel système lecture/écriture de Windows. Et donc en théorie les fichiers WSL devraient être accessibles sans bidouille particulière (en lecture, comme en écriture). Ce sont des fichiers NTFS comme les autres.
Je ne comprends pas quelle spécificité Linux (ou Windows) rend cela impossible ?
Sensibilité à la casse, il me semble que NTFS le gère depuis pas mal de temps.
Les droits, … peut-être les droits …un commentaire plus haut semblait indiquer que pour le montage des fichiers Windows dans l’espace WSL, WSL ne s’embêtait pas, hop! tout le monde en 777
Mais peut-être que dans l’espace des fichiers WSL, la gestion des droits est plus “fidèle” que pour ce type de montage, et implique de la “bidouille” ? Et que c’est cette “bidouille” qui implique la “bidouille” à base de 9P ?
Mais sinon, oui! ce serai sympa que MS accepte de vrai montages en natif d’autres FS que les siens. Même s’ils ne développent pas le “pilote”, en tout cas qu’ils ne l’interdisent/bloque pas.
Et qu’ils libèrent exFat. NTFS n’étant plus vraiment un problème sous Linux.