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 Windows Store:
Chaque distribution que vous installez via le magasin est installée dans le répertoire appdata de cette application. Exemple:
C:\Users\<username>\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState- benhillis
Pour WSL2, vous pouvez accéder au répertoire personnel à partir de Windows (Windows 10 build 18342) comme ceci :
\\wsl$Dans les itérations précédentes du sous-système Windows pour Linux, le système de fichiers Ubuntu était à %localappdata%\Lxss (p. ex., C:\Users\Username\AppData\Local\Lxss - remplacer le Utilisateur avec votre nom d'utilisateur sous Windows). Voir le billet de blog WSL sur la prise en charge du système de fichiers:
Le système de fichiers principal utilisé par WSL est VolFs. Il est utilisé pour stocker les fichiers système Linux, ainsi que le contenu de votre répertoire personnel Linux. En tant que tel, VolFs prend en charge la plupart des fonctionnalités fournies par Linux VFS, y compris 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 de VFS, en utilisant
%LocalAppData%\lxss\rootfscomme stockage de support. De plus, quelques points de montage VolFs supplémentaires existent, notamment/rootet/homequi sont montés en utilisant%LocalAppData%\lxss\rootet%LocalAppData%\lxss\homerespectivement. La raison de ces montages séparés est que lorsque vous désinstallez WSL, les répertoires personnels ne sont pas supprimés par défaut, de sorte que tous les fichiers personnels qui y sont stockés seront conservés.
PRÉCAUTION
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 et une perte de données dans le sous-système Ubuntu! (Merci à Rich Turner pour avoir suggéré ces mots d'avertissement!) C'est absolument pas soutenu. Du même article de blog:
Interopérabilité avec Windows
Alors que les fichiers VolFs sont 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 ne dispose pas des EAS nécessaires à VolFs, donc VolFs ne sait pas quoi faire avec le fichier et l'ignore simplement. De nombreux éditeurs supprimeront également l'EAS lors de l'enregistrement d'un fichier existant, rendant à nouveau le fichier inutilisable dans WSL.
Votre système de fichiers Windows se trouve à /mnt/c dans l'environnement shell Bash.
Source: Le 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 se trouve à un autre emplacement:
%localappdata%\lxss\home\{username}ou:
C:\Users\{user}\AppData\Local\lxss\{username}Où {user} est votre nom d'utilisateur Windows et {username} est votre nom d'utilisateur UNIX défini lors de l'installation.
Le répertoire racine serait donc:
%localappdata%\lxssNotez 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" de l'Explorateur.
Si vous installez Linux à partir de MS Market:
ils ont placé des distributions sous:
$ cat /proc/registry/HKEY_CURRENT_USER/Software/Microsoft/Windows/CurrentVersion/Lxss/\{861c29b4-ebe2-49a5-8a22-7e53a27934a0\}/BasePathC:\Users\user\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalStateDistribution 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/rootfsPS. J'ai utilisé Cygwin pour explorer les clés de registre.
Si vous utilisez PowerShell pour le même objectif, les commandes seraient:
# 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\LocalStateVous pouvez ouvrir rapidement Bash à partir d'une fenêtre de l'Explorateur de fichiers du dossier ouvert en tapant bash dans la barre de localisation.
Ça suffit.
Vous pouvez également ajouter un élément de menu contextuel. Personnellement, je ne le recommande pas si ce 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/
La seule chose qui a fonctionné pour moi était %localappdata%\lxss\home\{username}, où le {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 lxss du dossier caché refuse d'apparaître dans C:\Users\WINDOWS-USER\AppData\Local\, et aussi donner le plein C:\ le chemin avec le nom d'utilisateur Windows et BASH ne fonctionne pas non plus.
Et veuillez créer un raccourci sur le bureau pour ce qui fonctionne.
Pour ceux qui recherchent l'emplacement de l'image:C:\Users\[username]\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\État local \ ext4.vhdx
NOTER
Nous (l’équipe WSL) [vous recommandons FORTEMENT de ne PAS vous lancer dans la distribution Linux] folders](Do not change Linux files using Windows apps and tools - Windows Command Line)
). Si vous le faites, la perte de données et / ou la corruption sont TRÈS probables
Nous travaillons à améliorer ce scénario d’interopérabilité et annoncerons tout progrès sur notre blog: Windows Command Line
@DannyStaple Si vous devez modifier les autorisations sur les fichiers/dossiers de votre distribution Linux à partir de Windows, utilisez ’ wsl.exe’, par exemple ’ wsl chmod 600~/.ssh / id*` - ne copiez pas les fichiers dans ces dossiers via le système de fichiers Windows.
@mehrdad WSL implémente un serveur de fichiers P9, exposant/rassemblant les fichiers depuis/vers le système de fichiers de la distribution comme le ferait n’importe quel serveur de fichiers P9. De cette façon, il n’y a pas de métadonnées NTFS à organiser. Veuillez regarder la session de Craig Loewen & Ben Hillis à Build 2919 pour plus d’informations
@ RichTurner J’ai trouvé qu’il y a une raison très spécifique (et ennuyeuse) - les politiques d’entreprise marquant le .un dossier ssh avec les mauvaises autorisations signifie à plusieurs reprises qu’il faut marquer la structure comme “interdite” aux scripts d’entreprise. Mais en général - je serais d’accord avec vous.
Bien que cela ressemble à des boîtes avec des mises à jour plus récentes - cela ne se produit plus.
@ RichTurner: Pourquoi ne tunnellisez-vous pas les métadonnées Linux comme vous le faites déjà pour les métadonnées NTFS?
@mehrdad Nous le faisons en 1903 et plus tard via le nouveau serveur P9.
@ RichTurner: Merci pour la réponse! Je suis confus cependant… 1903 nécessite d’y accéder en tant que ressource réseau, n’est-ce pas? Si vous tunneliez les attributs de la même manière que vous tunneliez les métadonnées NTFS, il serait possible de simplement modifier les fichiers localement. Cela me suggère que ce n’est pas exactement ce que vous faites?
@ RichTurner: * " De cette façon, il n’y a pas de métadonnées NTFS à organiser."* Oui… donc, le tunneling NTFS n’est pas ce que vous faites, en contradiction avec ce que vous avez dit plus tôt. Nous revenons donc à ma première question: n’avez-vous pas tunnellisé les métadonnées WSL au lieu d’utiliser un serveur de fichiers, tout comme NTFS le fait déjà avec d’autres métadonnées?
@mehrdad Où ai-je dit que nous étions en train de rassembler des métadonnées NTFS? P9 rassemble les métadonnées des fichiers (horodatages, autorisations, nom de fichier, etc.), pas les données NTFS.