Se si crea un file in bash (toccare /root/foo.txt) che appare nelle directory nascoste durante la AppData\Local\Lxss\ modifica, non lo cambia in bash. Peggio ancora se lo cambi di nuovo in bash, il file che hai modificato tramite explorer viene bloccato!

C'è qualche vero mount point su C:\?

Dov'è nascosta l'immagine reale ?? (come fa il file system a riscrivere in un file di immagine in realtà?)

0:14:29 in questo https://channel9.msdn.com/Events/Build/2016/C906 sembra sostenere che avrai pieno accesso da explorer. 0:16:30 ti mostrano AppData\Local\Lxss\ ma non menzionano una volta che i tuoi file non si sincronizzeranno come ho descritto.

I nuovi file creati tramite Esplora risorse di Windows probabilmente non vengono visualizzati in bash perché mancano attributi speciali LXSS NTFS.

Quando LXSS crea file nella radice LXSS, allega informazioni aggiuntive tramite attributi NTFS per archiviare cose che non possono essere rappresentate dagli attributi NTFS standard, come le autorizzazioni per i file Linux. Se questi mancano, i file non vengono visualizzati.

Ciò è supportato dal fatto che se si crea un file in bash e quindi ne si fa una copia con Esplora risorse, esso appare in bash. Ciò è presumibilmente perché tutti gli attributi speciali LXSS sono stati duplicati con il file.

Anche il livello del file system LXSS sembra memorizzare nella cache il file system, quindi le voci della directory in bash non rifletteranno lo stato reale del file system se i file vengono aggiunti o eliminati fino all'arresto di tutti i terminali bash (che termina la sessione LXSS nel servizio LXSS e quindi cancella la cache).

Ok, sembra che le cose su AppData\Local\Lxss\siano modificabili e si sincronizzeranno nuovamente con la sessione bash di Ubuntu.

Devi chiudere completamente bash. E non puoi creare nuovi file.

Strano come Microsoft sembra dire che non puoi.

Tuttavia, oltre a essere noioso, questo non è ancora molto utilizzabile in quanto la creazione di nuovi file non sembra funzionare.

Non so se la sessione bash metta roba in ram o cosa, ma Microsoft può farlo accadere, sembra ... Se lo scelgono.

Quello che funziona per me è copiare con bash invece di usare Explorer.

Il C-drive è a / mnt / c così al fine di copiare la cartella C: \ tmp \ test1 a / tmp / nella vostra directory home bash fare: cp -r /mnt/c/tmp/test1 ~/tmp.

Penso che troverai questo ... incredibilmente utile. Ci sono molte informazioni utili lì, ma possono essere riassunte come si applica qui in una sezione:

Interoperabilità con Windows

Mentre i file VolFs sono archiviati in file regolari su Windows nelle directory sopra menzionate, l'interoperabilità con Windows non è supportata. Se un nuovo file viene aggiunto a una di queste directory da Windows, non ha gli EA necessari ai VolF, quindi i VolF non sanno cosa fare del file e semplicemente lo ignorano. Molti editor rimuoveranno anche gli EA durante il salvataggio di un file esistente, rendendo nuovamente inutilizzabile il file in WSL.

Inoltre, poiché VFS memorizza nella cache le voci della directory, eventuali modifiche a quelle directory che vengono eseguite da Windows mentre WSL è in esecuzione potrebbero non essere riflesse in modo accurato.

L'articolo parla anche delle specifiche del filesystem e degli attributi estesi. Ma in sintesi, la modifica dei file WSL da Windows è un no-go.

Fino a quando non hanno risolto il problema, ho installato cygwin sshd per la visibilità sul file system NTFS nativo ed eseguito Ubuntu sshd per la visibilità sui file lsxx linux. usa apt-get per installare sshfs e win-sshfs per fare montaggi in ogni modo. È un hack circolare ma per ora funziona per me.

Se non volevi pasticciare con cygwin sshd, puoi usare cygwin ssh per scp i file avanti e indietro.

L'uso di cygwin sshd aiuta a risolvere i problemi relativi alle autorizzazioni dei file utilizzando un account amministratore reale nel file .ssh / config. Ho avuto alcune strane autorizzazioni di accesso passando attraverso l'interfaccia DevFS / NTFS.