Où se trouve le répertoire racine du système de fichiers Ubuntu dans le sous-système Windows pour Linux et inversement?

J'ai installé le sous-système Ubuntu sur Windows 10 (après avoir activé la fonctionnalité dans les paramètres), mais où se trouve le répertoire racine du système de fichiers Ubuntu dans le lecteur?

Pour Ubuntu installé à partir du magasin Windows:

Chaque distribution que vous installez via le magasin est installée dans le répertoire appdata de cette application. Par exemple: C:\Users\<username>\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState - benhillis

Dans les versions précédentes du sous-système Windows pour Linux, le système de fichiers Ubuntu était %localappdata%\Lxss: (par exemple, C:\Users\Username\AppData\Local\Lxssremplacez le nom d' utilisateur par votre nom d'utilisateur sous Windows). Voir l' article du blog WSL sur le support du système de fichiers :

Le système de fichiers principal utilisé par WSL est VolF. Il est utilisé pour stocker les fichiers système Linux, ainsi que le contenu de votre répertoire de base Linux. En tant que tels, les VolF prennent en charge la plupart des fonctionnalités fournies par le système de Linux VFS, notamment les autorisations Linux, les liens symboliques, les FIFO, les sockets et les fichiers de périphérique.

VolFs est utilisé pour monter le répertoire racine VFS, en utilisant %LocalAppData%\lxss\rootfscomme stockage de sauvegarde. En outre, quelques volfs supplémentaires points de montage existent, notamment /rootet /homequi sont montés à l' aide %LocalAppData%\lxss\rootet %LocalAppData%\lxss\homerespectivement. La raison de ces montages séparés est que, lorsque vous désinstallez WSL, les répertoires de base ne sont pas supprimés par défaut. Par conséquent, tous les fichiers personnels qui y sont stockés sont conservés.

MISE EN GARDE

La création / modification de fichiers dans le sous-système Linux à l'aide d'applications et d'outils Windows peut entraîner une corruption des données et une perte de données dans le sous-système Ubuntu! (Merci à Rich Turner d' avoir suggéré ces mots de prudence!) Ce n'est absolument pas supporté. Du même article de blog:

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 évaluations requises par les VolF. Par conséquent, les VolF ne savent pas quoi faire avec le fichier et l'ignore simplement. De nombreux éditeurs retirent également les EA lors de l’enregistrement d’un fichier existant, le rendant ainsi inutilisable dans WSL.

Votre système de fichiers Windows est situé /mnt/cdans l'environnement du shell Bash.

Source: blog de Dustin Kirkland , howtogeek

Cela semble avoir changé depuis l'introduction de Bash et ne s'applique pas aux distributions du Windows Store, ou peut-être n'est-il pas cohérent pour tous les systèmes, car mon répertoire personnel est situé à un autre emplacement:

%localappdata%\lxss\home\{username}

ou:

C:\Users\{user}\AppData\Local\lxss\{username}

Où se {user}trouve votre nom d'utilisateur Windows et {username}votre nom d'utilisateur UNIX lors de l'installation.

Donc, le répertoire racine serait:

%localappdata%\lxss

Notez que le répertoire racine peut ne pas être visible dans l'Explorateur Windows à partir du %localappdata%répertoire. Vous devriez pouvoir y accéder de toute façon en le tapant dans la "barre d'adresse" d'Explorer.

Si vous installez Linux à partir de MS Market:

• Ubuntu gratuit dans Windows Store
• Free Open Suse dans le magasin Windows

ils ont placé des distributions sous:

$ cat /proc/registry/HKEY_CURRENT_USER/Software/Microsoft/Windows/CurrentVersion/Lxss/\{861c29b4-ebe2-49a5-8a22-7e53a27934a0\}/BasePath
C:\Users\user\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState

La distribution par défaut définie par:

bash# cat /proc/registry/HKEY_CURRENT_USER/Software/Microsoft/Windows/CurrentVersion/Lxss/DefaultDistribution
{861c29b4-ebe2-49a5-8a22-7e53a27934a0}

La racine Linux est plus profonde:

c:/Users/user/AppData/Local/Packages/46932SUSE.openSUSELeap42.2_022rs5jcyhyac/LocalState/rootfs

PS J'ai utilisé Cygwin pour explorer les clés de registre.

Si vous utilisez PowerShell pour le même objectif, les commandes sont les suivantes:

# obtain the value of the ID of the default Linux distribution (and store it in a variable to avoid escaping characters issues):
$DEFAULT_LXSS_ID = (Get-ItemPropertyValue -Path REGISTRY::HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss\ -name DefaultDistribution)

# which will have a value like:
echo  $DEFAULT_LXSS_ID
{bde539d6-0c87-4e12-9599-1dcd623fbf07}

# display the directory containing the rootfs Windows directory (mapped to the / Linux directory)
Get-ItemPropertyValue -Path REGISTRY::HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss\$DEFAULT_LXSS_ID -name BasePath | Format-List -property "BasePath"
%LocalAppData%\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\LocalState

PPS. https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-not-change-linux-files-using-windows-apps-and-tools/

La seule chose qui a fonctionné pour moi a été %localappdata%\lxss\home\{username}, où {username}est votre nom d'utilisateur BASH que vous lui avez donné lors de l'installation. Pour une raison quelconque, après avoir montré le dossier caché, lxss refuse d’apparaître C:\Users\WINDOWS-USER\AppData\Local\et donne également le C:\chemin complet avec windows et le nom d’utilisateur BASH ne fonctionne pas non plus.

Et s'il vous plaît créer un raccourci sur le bureau pour ce qui fonctionne.

Vous pouvez rapidement ouvrir Bash à partir d'une fenêtre de l'explorateur de fichiers du dossier ouvert en tapant bashdans la barre d'adresse.

C'est assez.

Vous pouvez également ajouter un élément de menu contextuel. Personnellement, je ne le recommande pas s'il n'est pas nécessaire, car l'ajout de raccourcis au menu contextuel utilise plus de RAM.

https://www.howtogeek.com/270810/how-to-quickly-launch-a-bash-shell-from-windows-10s-file-explorer/