WSL (ubuntu / windows) O AppData \ Local \ Lxss não sincroniza de fato com o Ubuntu, idéias?

Question

Se você criar um arquivo no bash (toque /root/foo.txt) que aparece nos diretórios ocultos em AppData\Local\Lxss\ , modificando-o, não o altera no bash. Pior se você alterá-lo novamente no bash o arquivo que você alterou através do explorador fica danificado!

Existe algum ponto de montagem real em 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 link parece afirmar que você terá acesso total ao explorador. 0:16:30 eles mostram AppData\Local\Lxss\ , mas não mencionam uma vez que seus arquivos não serão sincronizados como descrevi.

    

Answer 1

Novos arquivos criados através do Windows Explorer possivelmente não aparecem no bash porque não possuem 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 do NTFS para armazenar itens que não podem ser representados pelos atributos padrão do NTFS, como as permissões de arquivo do Linux. Se estes estão faltando, os arquivos não aparecem.

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

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

    

Answer 2

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

A unidade C está em / mnt / c, para copiar a pasta C: \ tmp \ test1 para / tmp / em seu diretório base bash do: cp -r /mnt/c/tmp/test1 ~/tmp .

    

Answer 3

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

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

Estranho como a Microsoft parece dizer que você não pode.

No entanto, além de ser irritante, isso ainda não é muito útil, já que fazer novos arquivos parece não funcionar.

Eu não sei se a sessão bash coloca coisas em memória RAM ou o que mas a Microsoft pode fazer isso acontecer parece .. Se eles escolherem.

    

Answer 4

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

Interoperability with Windows

While VolFs files are stored in regular files on Windows in the directories mentioned above, interoperability with Windows is not supported. If a new file is added to one of these directories from Windows, it lacks the EAs needed by VolFs, so VolFs doesn’t know what to do with the file and simply ignores it. Many editors will also strip the EAs when saving an existing file, again making the file unusable in WSL.

Additionally, since VFS caches directory entries, any modifications to those directories that are made from Windows while WSL is running may not be accurately reflected.

O artigo também fala sobre as especificidades do sistema de arquivos e os atributos estendidos. Mas, em resumo, modificar arquivos WSL a partir do Windows não é permitido.

    

Answer 5

Até que isso funcionasse, instalei o cygwin sshd para obter visibilidade do sistema de arquivos NTFS nativo e executei o ubuntu sshd para visibilidade dos arquivos linux do lsxx. use o apt-get para instalar o sshfs e o win-sshfs para fazer montagens de cada maneira. É uma invasão, mas funciona para mim por enquanto.

Se você não quisesse mexer com o cygwin sshd, você poderia usar o cygwin ssh para escanear os arquivos.

Usar o cygwin sshd ajuda a solucionar problemas de permissões de arquivos usando uma conta de administrador real no arquivo .ssh / config. Eu tinha algumas permissões de acesso estranhas passando pela interface do DevFS / NTFS.