Manipulate Linux/Ubuntu subsystem files from via the Windows environment

[BJobsis]

• A brief description: When I try to create a file from Windows10 (using Sublime Text, etc) into the Linux Ubuntu subsystem the file is created, but afterwards the file can't be seen from within the subsystem. I bypass this by creating (and cutting/pasting) the file via the NANO cmd.

• Expected results It would be nice (like in Apple's OSX terminal environment) to manipulate files from outside the Linux subsystem. In my opinion (as a developer) this would mean a big step forward in the usability of the Ubuntu subsystem.

*My Windows build number: W10 Build 1607 14393.576.

Regards, Barry Jobsis (barry.jobsis@gmail.com)

[BJobsis]

The new possibilities in de Fall Creators Update look great, certainly using .exe files like Sublime Text within WSL. But I think I'm still bound to use 'nano' to edit files within WSL.

Will there be options in the future to edit/create WSL files within Windows? And, again in the future, will the WSL environment/dir's,etc become visible and manageable within Windows?

[therealkenc]

But I think I'm still bound to use 'nano' to edit files within WSL.

Native Linux Sublime works very well in WSL if you are willing to go the VcXsrv route. But yeah for now officially vim and nano.

And, again in the future, will the WSL environment/dir's,etc become visible and manageable within Windows?

They have their top men on it per the User Voice.

[marcelgwerder]

At this point this is the most important feature for me as a web developer. All I want is to edit my code from windows, everything else should happen within WSL. Having the code on the Windows filesystem works 99% of the time but there is that one percent where the application thinks it's running on Linux and does all the crazy things the Windows filesystem doesn't handle properly (permissions, directory separators etc.). This reminds me of working with Docker for Windows which had the same issues because the code was residing on Windows and I ultimately had to abandon that solution. The only way all the code I use runs seamlessly is when it not only runs in Linux but also is on such a filesystem.

Just a small example of some code from the core of a PHP CMS I have to work with:

// Replace \ with _ if on Windows
if (DIRECTORY_SEPARATOR == '\\')
{
    $key = str_replace('\\', '_', $key);
}

You can imagine that this doesn't behave as intended on WSL because the Windows check will fail and the resulting cache key, which is used as the file name, keeps the backslashes in it and will create a number of directories instead of a file.

Definitely a huge :+1: for this!

[pharmmd-rich]

I still don't understand the desire to directly edit the files on the WSL filesystem. WSL provides a share (/mnt/c or similar) that allows you to perform the same thing, safely and without issue (I've never encountered one at least).

However, performance of the WSL filesystem in general is still very slow, I still use a CentOS VM on VMWare and use shared folders. It is exponentially faster and more stable to do stuff that way.

Hopefully the WSL team focuses on speeding things up in the future.

[kayakyakr]

@pharmmd-rich For me, it's mostly a speed issue. DriveFS is significantly slower than VolFS. If I was going straight Vim, I'd be able to manage, but if I want to run an integrated environment (Atom/VisualStudio Code, Docker services, linux server), I've gotta be on DriveFS and it's at times painfully slow.

[teras]

I am also in the need to edit files directly on WSL fiesystem, and I will give you an example why is that.

I need to host my project in WSL for hundreds of reasons, some of which are unix permissions, symbolic links, compatibility with other open source tools, fixed directory structure etc.

Now, I need an IDE to edit my project (let's pretend that this is IntelliJ or Netbeans). Then I am stucκ to use the Linux version of the IDE (which again means gigabytes of dependencies, not to mention the ugly graphics).

This is my only reason up to now that I continue developing on my Linux box, instead of booting into my (test-only) Windows partition.

2017-12-08 20:12 GMT+02:00 Richard Campbell notifications@github.com:

I still don't understand the desire to directly edit the files on the WSL filesystem. WSL provides a share (/mnt/c or similar) that allows you to perform the same thing, safely and without issue (I've never encountered one at least).

However, performance of the WSL filesystem in general is still very slow, I still use a CentOS VM on VMWare and use shared folders. It is exponentially faster and more stable to do stuff that way.

Hopefully the WSL team focuses on speeding things up in the future.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Microsoft/WSL/issues/1524#issuecomment-350332825, or mute the thread https://github.com/notifications/unsubscribe-auth/AAkKuC6sKQ2Ncw1819JuSiHjItC6ccPPks5s-Xv4gaJpZM4LR5BU .

[Gannalech]

Here's a workaround: after setting obcaseinsensitive=0 in the registry and fixing any path issues install Sandboxie (any sandboxing program will do). Run the IDE / text editor sandboxed so that it does not directly save to lxss. Use rsync under Bash to update the files.

[leo-cydar]

@Gannalech that is a terrible workaround.

[Deltrego]

@b71729 maybe you need more detail: I enabled case sensitivity on an almost new w10 install and luckily had no issues. Without it you can still edit linux files with non-conflicting names. I tried to avoid third party tools but could not make VirtualStore do what was needed (tried a few things like shimming the text editor so that run as non-admin any writes to lxss folder would be virtualized). With Sandboxie I created a custom "lxss" sandbox w/ no auto recovery, no deletion, protecting only the lxss folder. Then I defined the following aliases under bash:

alias *1='"/mnt/c/Program Files/Sandboxie/Start.exe" /box:lxss explorer.exe /root,C:\\Users\\$USER\\AppData\\Local\\lxss'
alias *2='rsync -r /mnt/c/Sandbox/$USER/lxss/user/current/AppData/Local/lxss/ /.'
alias *3='rm -rf /mnt/c/Sandbox/$USER/lxss/user/current/AppData/Local/lxss/*'

$USER represents the Windows username, no spaces. Not a predefined variable. *1 opens a sandboxed Explorer window from bash (any opened file is also sandboxed). *2 syncs changes, this should preserve original permissions, using mv would make them 777 *3 deletes lxss folder from the sandbox (to avoid stale files reverting any changes done in bash) Hope someone finds this useful.

[BJobsis]

Ls,

Tested create file in W10 1903 (via WSL explore.exe) with Sublime Text and read back in WSL with Nano. And vice versa. Both actions worked perfect. I close this request now as I consider it as solved. Development team thanks for your effort.

Regards, Barry

[ilqvya]

@BJobsis what about symlink folders ?

[therealkenc]

Shipped in 18342 aka 1903.

[BJobsis]

Ilya, I never used symlinks. I understand what they do but don't see any added value in this case. For me: I needed a way to edit a file in WSL and use in in W10 and vica versa. That works now and so my problem is solved. Regards,Barry

On Thu, Oct 31, 2019 at 4:55 PM Ilya Polishchuk notifications@github.com wrote:

@BJobsis https://github.com/BJobsis what about symlink folders ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/microsoft/WSL/issues/1524?email_source=notifications&email_token=ACFBUZIFKCL42SZ5PK3MR3LQRL5XBA5CNFSM4C2HSBKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECYJKLA#issuecomment-548443436, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACFBUZJFKFRCOCAW6NWIJPTQRL5XBANCNFSM4C2HSBKA .