Si vous créez un fichier en bash (touchez /root/foo.txt) qui apparaît dans les répertoires cachés en le AppData\Local\Lxss\ modifiant, il ne le change pas en bash. Pire, si vous le modifiez à nouveau dans bash, le fichier que vous avez modifié via l'explorateur est détruit!

Y a-t-il un vrai point de montage C:\?

Où se cache la vraie image ?? (comme le système de fichiers réécrit dans un fichier image en réalité?)

0:14:29 dans ce https://channel9.msdn.com/Events/Build/2016/C906 semble prétendre que vous aurez un accès complet depuis l'explorateur. 0:16:30 ils vous montrent AppData\Local\Lxss\ mais ne mentionnent pas une seule fois que vos fichiers ne seront pas synchronisés comme je l'ai décrit.

Les nouveaux fichiers créés via l'Explorateur Windows n'apparaissent peut-être pas dans bash car il leur manque des attributs LXSS NTFS spéciaux.

Lorsque LXSS crée des fichiers à la racine LXSS, il leur attache des informations supplémentaires via des attributs NTFS pour stocker des éléments qui ne peuvent pas être représentés par les attributs NTFS standard, tels que les autorisations de fichiers Linux. Si ceux-ci sont manquants, les fichiers n'apparaissent pas.

Ceci est soutenu par le fait que si vous créez un fichier en bash, puis en faites une copie avec l'Explorateur Windows, il apparaît dans bash. Cela est probablement dû au fait que tous les attributs spéciaux LXSS ont été dupliqués avec le fichier.

La couche du système de fichiers LXSS semble également mettre en cache le système de fichiers, de sorte que les entrées de répertoire dans bash ne refléteront pas l'état réel du système de fichiers si des fichiers sont ajoutés ou supprimés jusqu'à ce que tous les terminaux bash soient arrêtés (ce qui met fin à la session LXSS dans le service LXSS et donc vide le cache).

Ok, il semble que le contenu AppData\Local\Lxss\soit modifiable et se synchronisera de nouveau avec la session bash d'Ubuntu.

Vous devez fermer complètement bash. Et vous ne pouvez pas créer de nouveaux fichiers.

Étrange comme Microsoft semble le dire.

Cependant, en plus d'être ennuyeux, cela n'est toujours pas très utile car la création de nouveaux fichiers ne semble pas fonctionner.

Je ne sais pas si la session bash met des trucs dans ram ou quoi, mais Microsoft peut y arriver, il apparaît .. S'ils choisissent.

Ce qui fonctionne pour moi, c'est de copier avec bash au lieu d'utiliser Explorer.

Le lecteur C est à / mnt / c ainsi afin de copier le dossier C: \ tmp \ test1 / tmp / dans votre bash répertoire faire: cp -r /mnt/c/tmp/test1 ~/tmp.

Je pense que vous trouverez cela ... incroyablement utile. Il y a beaucoup d' informations utiles ici, mais elles peuvent être résumées comme elles s'appliquent ici dans une section:

Interopérabilité avec Windows

Bien que les fichiers VolF soient stockés dans des fichiers normaux sous Windows dans les répertoires mentionnés ci-dessus, l'interopérabilité avec Windows n'est pas prise en charge. Si un nouveau fichier est ajouté à l'un de ces répertoires à partir de Windows, il manque les EA nécessaires aux VolF, donc VolF ne sait pas quoi faire avec le fichier et l'ignore simplement. De nombreux éditeurs suppriment également les EA lors de l'enregistrement d'un fichier existant, ce qui rend le fichier inutilisable dans WSL.

En outre, étant donné que VFS met en cache les entrées de répertoire, toutes les modifications apportées aux répertoires qui sont effectuées à partir de Windows pendant l'exécution de WSL peuvent ne pas être reflétées avec précision.

L'article parle également des spécificités du système de fichiers et des attributs étendus. Mais en résumé, la modification des fichiers WSL à partir de Windows est un pas.

Jusqu'à ce que cela fonctionne, j'ai installé cygwin sshd pour la visibilité sur le système de fichiers NTFS natif et exécuté le ubuntu sshd pour la visibilité sur les fichiers linux lsxx. utilisez apt-get pour installer sshfs et win-sshfs pour faire des montages dans chaque sens. C'est un hack détourné mais fonctionne pour moi pour l'instant.

Si vous ne voulez pas jouer avec le sshd de cygwin, vous pouvez utiliser le sshd de cygwin pour parcourir les fichiers d'avant en arrière.

L'utilisation de cygwin sshd permet de contourner les problèmes d'autorisations de fichiers en utilisant un vrai compte administrateur dans le fichier .ssh / config. J'avais d'étranges autorisations d'accès via l'interface DevFS / NTFS.