Se você criar um arquivo no bash (toque em /root/foo.txt) que apareça nos diretórios ocultos ao AppData\Local\Lxss\ modificá-lo, ele não será alterado no bash. Pior ainda, se você alterá-lo novamente no bash, o arquivo que você alterou através do Explorer será derrotado!

Existe algum ponto de montagem real C:\?

Onde está a imagem real escondida? (como o sistema de arquivos está gravando de volta para um arquivo de imagem na realidade?)

0:14:29 neste https://channel9.msdn.com/Events/Build/2016/C906 parece alegar que você terá acesso total a partir do explorer. 0:16:30 eles mostram, AppData\Local\Lxss\ mas não mencionam uma vez que seus arquivos não serão sincronizados como eu descrevi.

Novos arquivos criados pelo Windows Explorer possivelmente não estão aparecendo no bash porque estão faltando atributos especiais do LXSS NTFS.

Quando o LXSS cria arquivos na raiz do LXSS, ele anexa informações adicionais a eles por meio de atributos NTFS para armazenar coisas que não podem ser representadas pelos atributos NTFS padrão, como permissões de arquivo Linux. Se estes estiverem ausentes, os arquivos não serão exibidos.

Isso é suportado pelo fato de que, se você criar um arquivo no bash e depois fazer uma cópia dele no Windows Explorer, ele aparecerá no bash. Isso provavelmente ocorre porque todos os atributos especiais do LXSS foram duplicados com o arquivo.

A camada do sistema de arquivos LXSS também parece armazenar em cache o sistema de arquivos, portanto, as entradas do diretório no bash não refletirão o estado real do sistema de arquivos se os arquivos forem adicionados ou excluídos até que todos os terminais do bash sejam interrompidos (o que termina a sessão LXSS no serviço LXSS e, portanto, limpa o cache).

Ok, parece que as coisas AppData\Local\Lxss\são modificáveis ​​e serão sincronizadas novamente com a sessão do bash do Ubuntu.

Você deve fechar o bash completamente. E você não pode criar novos arquivos.

Por mais estranho que a Microsoft pareça dizer que você não pode.

No entanto, além de ser irritante, isso ainda não é muito utilizável, pois a criação de novos arquivos não parece funcionar.

Eu não sei se a sessão do bash coloca coisas no ram ou o quê, mas a Microsoft pode fazer isso acontecer, parece .. Se eles escolherem.

O que funciona para mim é copiar com o bash em vez de usar o Explorer.

O C-drive está em / mnt / c por isso, para copiar a pasta C: \ tmp \ test1 para / tmp / no seu diretório home do bash fazer: cp -r /mnt/c/tmp/test1 ~/tmp.

Eu acho que você vai achar isso ... incrivelmente útil. Há bastante informação útil lá, mas pode ser resumida como se aplica aqui em uma seção:

Interoperabilidade com o Windows

Embora os arquivos VolFs sejam armazenados em arquivos regulares no Windows nos diretórios mencionados acima, a interoperabilidade com o Windows não é suportada. Se um novo arquivo é adicionado a um desses diretórios do Windows, ele não possui os EAs necessários para o VolFs, portanto, o VolFs não sabe o que fazer com o arquivo e simplesmente o ignora. Muitos editores também eliminam os EAs ao salvar um arquivo existente, novamente tornando o arquivo inutilizável na WSL.

Além disso, como o VFS armazena em cache as entradas de diretório, quaisquer modificações feitas nesses diretórios feitas no Windows enquanto a WSL está em execução podem não ser refletidas com precisão.

O artigo fala sobre as especificidades do sistema de arquivos e os atributos estendidos também. Mas, em resumo, a modificação de arquivos WSL do Windows não é possível.

Até que eles resolvam isso, instalei o cygwin sshd para obter visibilidade no sistema de arquivos NTFS nativo e executei o ubuntu sshd para ter visibilidade nos arquivos lsxx linux. use o apt-get para instalar o sshfs e o win-sshfs para montar montagens de qualquer maneira. É um truque rotativo, mas funciona para mim por enquanto.

Se você não quiser mexer com o cygwin sshd, use o cygwin ssh para scp os arquivos para frente e para trás.

O uso do cygwin sshd ajuda a solucionar problemas de permissões de arquivo usando uma conta de administrador real no arquivo .ssh / config. Eu tinha algumas permissões de acesso estranhas na interface do DevFS / NTFS.