![Avatar of Rich Turner [MSFT]](data:image/jpg;base64,/9j/4AAQSkZJRgABAQEAtAC0AAD/2wBDAA0JCgsKCA0LCgsODg0PEyAVExISEyccHhcgLikxMC4pLSwzOko+MzZGNywtQFdBRkxOUlNSMj5aYVpQYEpRUk//2wBDAQ4ODhMREyYVFSZPNS01T09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0//wAARCAArACwDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDg/LNX9O0uW7IK4K7tuO/1qFWI4zXWeESFEkzqSq+gzzXK5NHr1IJRuiIaGUXbNbrtx94JzWPqVpBZkHa6g9ycj+Vd3NeQzRvIrkIp5JHSuT8Qsklq23knkZBFRGTbszBpw96LM1LLeOMGg6S5OQDW3ptrC9jbu24ExqT+Vao0uJ/mjbC54BJqbyvoe4o0HFOS3OARMn77fpXouhR20WgxOyKUMOZDj7xyc5rzdJADzmut8HSSzpdwopMe0ZzV1E7HmyceQ1NR2R6bsjhC72DkJ6e9ZGopA9irxRqC/wArEetbupyRG0PCouPmAAGfrXLy3ZdUVUCxK2Rx1qEYt8zUe5q2sWIUVJGVVGAOOgrWSGRV2rPJgegX/Cufj1CRu6j6AD+VWf7QlP8Ay1C+wNSpJHtvDycUk9jMtdK0uO2MlwLiVz9zoAfw/A1taLcx2Nr5kKgL8rFduCxfA2jA+mPoamMMX9n237pPvD+EehplzaQf2XAwjwfmbgnqrHH5ZNdTV9GeBzp7F/UI7a+tvNjQM1cpqmyACMY3gZI9un9a6fSeYXz3AP5iuQvlDXlwzZJVmAOfrWUI6iloR26mSFmWdAUHOT14qBxPu4ljP0cU6wA8ubj+H+hqAnnt09K05UbxrVbW5j//2Q==)
I have to provide this guidance at least 2-3 times a day so instead I am publishing it here so everyone can find / link-to this guidance.
There is one hard-and-fast rule when it comes to WSL on Windows:
DO NOT, under ANY circumstances, access, create, and/or modify files in your distro's filesystem using Windows apps, tools, scripts, consoles, etc.
Opening files using some Windows tools may read-lock the opened files and/or folders, preventing updates to file contents and/or metadata, essentially resulting in corrupted files/folders.
Creating/changing Linux files from Windows will likely result in data corruption and/or damage your Linux environment requiring you to uninstall & reinstall your distro!
Note: In beta versions of WSL, your "Linux files" are any of the files and folders under %localappdata%\lxss - which is where the Linux filesystem - distro and your own files - are stored on your drive. In supported versions of WSL, the filesystems for the distros you install via the Microsoft Store are stored elsewhere on disk … for good reason!
Do not create/modify Linux files from Windows apps/tools
What SHOULD I do?
To work on files using both Windows and Linux tools, store files in your Windows filesystem - this will enable you to access the same files from both Windows and from your Linux distros via /mnt/<drive>/<path> (e.g. /mnt/c/dev/project/...),
When you access files on your Windows filesystem from within Bash, WSL honors the NT filesystem behaviors (e.g. case-insensitivity), permissions, etc. so you can easily access the same files using both Windows tools and Bash tools without having to copy files back and forth between filesystems.
Therefore, be sure to follow these two rules in order to avoid losing files, and/or corrupting your data:
- DO store files in your Windows filesystem that you want to access/create/modify using Windows tools AND Linux tools
- DO NOT access / create / modify files in your Linux distros' filesystems from Windows apps, tools, scripts or consoles
Remember: There's a reason we store your distros' filesystems in non-obvious locations!
Why is this?
File metadata (e.g. permissions, ownership, timestamps, etc.) is stored for every file, folder, etc., on your storage devices. Alas, file metadata representation differs from one OS to another: Windows file metadata is different from Linux file metadata.
While it's the OS' job to store and update your file metadata, most of Windows doesn't know anything about Linux, nor Linux file metadata, and doesn't automatically add or update Linux file metadata for all Windows files because that would impose an unnecessary overhead on the vast majority of Windows users who will never run WSL.
It's WSL's job to write/update Linux file metadata for all the files under your Linux filesystem root (i.e. /), storing the Linux metadata in each file's NTFS extended attributes. WSL also synthesizes pseudo metadata for most of the files in your Windows filesystem.
The problem arises when, for example, you use a Windows app/tool to open, create and/or modify a file under your distro root: Since the file was created with a Windows tool, the file won't have any Linux file metadata (e.g. permissions, owner, access/update timestamps, etc.). Thus, to Linux, (which only receives Linux file metadata), the file may be reported as empty, may not even exist, or may have some metadata, but that metadata may not reflect the file's details resulted in the file's contents being corrupted.
Further, as in Linux, some Windows tools implement unusual filesystem access patterns to handle file updating and don't actually edit files in-place: When apps/tools save changes to a file, the original files are often deleted and re-created, etc. During such operations, NT file "extended properties" (i.e. Linux file permissions) are often not copied and are "lost".
For more background into how the WSL filesystem infrastructure works, be sure to read/watch this AWESOME blog & video which explains things in much more detail.
Please help us share this guidance far and wide - tweet, post and blog, linking back to this post!!
Thanks.
Update Log:
- [2017-03-14 - Updated "Why is this"; thanks to @mn in comments]
- Last Updated: [2019-01-15] - Minor updates & improvements
A problem that remains when working with the same files in both Windows and Bash (under /mnt/c, as per the guidance) is symlinks. Windows symlinks (and junctions) are not symlinks in WSL and vice versa. Ideally, they would be the same, but then we have the limitations that surround symlinks on Windows (and that seem to worsen for every Windows release).
If Windows users (normal and admins) could be allowed to create local-to-local symlinks with a developer mode setting or preferably by default, couldn’t there be full interop? That is, WSL understands Windows symlinks and junction points, translates their paths appropriately, and symlinks created from Bash are normal Windows symlinks (which are great but underused because of the permission problems).
It’s almost as if we were reading your mind!
https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/
We recently introduced a relaxation of the rules around creating Symlinks on Windows as a trial-balloon to perhaps broaden this relaxation further. Please give this a try and let us know how you get on.
Note: WSL will eventually be updated to support “Real” Windows Symlinks, but cannot yet see these NTFS symlinks. The team are on this and will work up a fix: https://github.com/Microsoft/BashOnWindows/issues/1475
Can I still delete Linux files using Windows tools?
Yes. Just be REALLY sure you want to delete them; once they’re gone, they’re gone!
that old tactical incompatibility rearing it’s head.
Ermmm … no. Simply a reality of trying to meld two OS environments which were built from a different set of philosophies, assumptions, architectural principles, etc.
Except that it’s ******* and you know it. You could perfectly well map NTFS ACLs to POSIX ACLs and use native permissions.
Assuming, of course, you actually wanted to support full compatibility, instead of just shipping the minimal necessary features to trap people in your walled garden again.
Not quite sure how allowing Linux binaries to run on Windows defines, let alone entraps one within, a “walled garden”.
Of course, we’d like to improve the integration between Linux and Bash over time, but we decided to spend our finite resources on increasing and improving our support for running more and more Linux binaries, tools, etc. vs. integrating the Windows and Linux security models.
Also, please keep your language PG – this is a family show.
It would be difficult/impossible to map Windows ACL to Posix ACLs because the two things are so different, and it’s obvious from your comment that you’re one of those Linux geeks that likes to bash on Windows even though you probably have very little actual experience using it.
As somebody who is sysadmin-level at both OSes, Windows ACLs are SOOO much more powerful than the POSIX ones. But yeah, it’s easier to just demonize Microsoft all the time rather than spend 5 seconds to think about the fact that Linux isn’t better than Windows in every conceivable way.
*bash on windows* !! haha! I see what you did there
Patrick, that’s funny
Thanks for shedding some light on this!
Or you could boot into Linux and access your NTFS partitions from Linux. Linux has no problem with that, or with any of 700 file systems it can work with.
“has no problem with that” isn’t actually factually true though: http://www.tuxera.com/community/ntfs-3g-faq/
Linux and Windows were built from different philosophies, which led to different archiectural choices, and different implementations of various features resulted in incompatibilities, strengths and weaknesses on both sides. We are trying to meld these two environments, allowing you to stay true to each, while interoperate as smoothly as possible when using both. This will inevitibly result in some gotcha’s and perhaps some limitations, but we expect these to remain pretty few and far between.
I don’t think Agron Selimaj’s comment should be summarily dismissed. I’ve used NTFS formatted USB drives on Linux without much of an issue for a while now. Maybe the support isn’t perfect, but it’s good enough for sending simple files back and forth. Meta-content divergence like permissions seem sanely handled. And I’d expect that an organization like Microsoft, with all it’s engineering resources could come up with an even better solution. Microsoft has tackled much more complicated problems in the past. From where I sit, despite the lineage difference between Linux and Windows storage subsystems, the there’s no technical reason why there can’t be tighter integration that supports many users’ needs.
TL;DR Dude wheres my EXT4?
this is the point I was looking for. Except why leave out the name?.
We hear ya, and encourage you to upvote here if you feel this is an important feature we should look into in the future: https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13818042-support-mounting-xfs-ext2-ext3-ext4-etc-partition
Is it advisable to create a link to that folder pointing to another drive?
$ ln -s /mnt/c/work ~/Work
Problem Solved
And that is advisable?
Yes, creating symlinks from WSL’s Linux filesystem to other folders in your Windows filesystem is fine – it is, after all, `interesting` is just a shortcut for `/mnt/c/long/path/to/somewhere/more/interesting/`
I’m assuming Windows Apps like Putty & WinSCP are exempted from this warning.
Please advise.
No: If these apps directly create/modify files under %localappdata%\lxss, the affected files are likely to be damaged too!
However, I think you’re misunderstanding the guidance here: One generally doesn’t directly modify files with Putty/WinSCP/etc. – one uses these apps to open command-line sessions and to send commands and/or data back and forth via via SSH/[t]ftp/etc. in these cases, any file operations will be performed within Bash (or which ever shell you run), so everything should work fine and no corruption should occur.
But why don’t you just make the user home into /mnt//Users/? For that matter, why is there no $win_userprofile (eg.) environment variable, or $win_systemdrive $win_path, … $win_**
One can run Windows version of Vim, Emacs, Git, etc. each of which store their settings in %homepath% (e.g. c:\users\rich\). These settings files configure the associated tool within Windows. If we link ~/ to %homepath%, bash would try to configure itself using your Windows settings and vice/versa – this generally leads to much swearing and unhappiness
WSL doesn’t appear to have any support for Xwin – so I am a bit confused with the recommended process of doing any development work. I am a little confused here – I tried getting emacs to work using mobaXterm’s xserver but it doesn’t resize correctly and makes coding a chore. What is the recommendation?
We’ve been very explicit about this from the start – we’re not aiming to support X/GUI apps. We’re not doing anything to prevent them from working – we’re just not focusing any effort on them at this time.
However, what MANY people are doing is cloning/copying/creating source code projects somewhere on their (fixed) C: D: drives and then using their favorite GUI editor (e.g. Visual Studio, VSCode, Atom, Sublime, Vim, Emacs) to edit the files, and use compilers and build tools in Bash to build, assemble, link and package, run and test their apps.
HTH.
“will likely result in data corruption and/or damage your Linux environment requiring you to uninstall & reinstall your distro”
I expect better than this from a blog on msdn. It is true that windows are not compatible with anything else since ms obviously chooses to make them hostile to other environments, eg still unable to mount HFS+ or ext4 or handle unix ending text files.
“I expect better than this from a blog on msdn” – I’m sorry – where would you rather we publish such guidance? We’ve already published this guidance in our official docs, and discussed it in our post and video detailing the inner workings of WSL’s filesystem support (https://blogs.msdn.microsoft.com/wsl/2016/06/15/wsl-file-system-support/), but many users haven’t found/read/understood the issue, so I wrote it up here in what I hope is pretty clear and unambiguous guidance.
This is nothing about hostility – it’s simply a reality that Windows and *NIX were born from different pholosophies, different architectural principles and different implemenation paths.
I believe it’s clear to most that WSL is explicitly trying to bridge the gap between Linux and Windows and to provide a way for users to enjoy whichever environment and toolset they prefer or need in order to get their work done.
> I believe it’s clear to most that WSL is explicitly trying to bridge the gap between Linux and Windows and to provide a way for users to enjoy whichever environment and toolset they prefer or need in order to get their work done.
And with limitations like this, cygwin is the better alternative, since it doesn’t eat my files.
“it doesn’t eat my files” – Neither will WSL if you avoid this one loophole. Plus with Bash/WSL, you get to run any unmodified x64 Linux binary directly on Windows – something that Cygwin cannot do.
Based on the text of the article (as opposed to the title) I presume you are not extending this to smb/samba or NFS mounted folders.
I still find it somewhat alarming as I have written files to a drive on my PC that I then physically moved to a Linux box. Done this many times and never detected an error.
It *seems* like this article is solely focused on a subdirectory under appdata which, except for cygwin, I’ve never encountered (and cygwin tried to guide one towards /mnt/cygdrive/… anyway).
Under what circumstances do you see people storing Linux stuff under appdata?
Right now, we don’t allow mounting of network drives and, since the OS hosting a folder shared via the network are responsible for storing those files, it’s unlikely that issues like those described above would exhibit on, for example, files stored on a remote Linux box running Samba or NFS, or on a remote Windows box running SMB.
I don’t know how you stored the files you’ve shared between Windows and Linux: I am guessing you used a FAT-formatted USB drive? In which case, there’s nothing for you to worry about – that’s a different scenario than the one discussed above.
As you infer, the issue described above only exists within the Bash on Ubuntu on Windows / Windows Subsystem for Linux (WSL) technology added to Windows 10 Anniversary update; it has nothing to do with Cygwin.
To be honest, it’s sounding to me like you should figure some deeper level of isolation for those files than just marking hidden and system if the problem is this severe even if it makes said files completely inaccessible from Windows userspace. At least for the final product. Current behaviour sounds fine for beta.
This is one of the key points of tension in WSL: We want it to live alongside the rest of Windows and to be easily accessible from either side, without having to enforce a tall barrier between the two, as experienced when running VM’s atop Hyper-V/VMWare/VirtualBox/etc.
Clearly we have room for improvement here, which is one of the reasons WSL is a “beta” feature, but until we can figure out a sound solution to this issue, follow the guidance and you’ll avoid this problem.
What about using winscp to access your files through a petty terminal I am working on an Apache site and having lots of trouble displaying an HTML background in a page on my Apache side even though other portions of the page enabled with SSI work I’m wondering if it’s because we’re using a Windows tool to modify Linux files
The issue above isn’t affected by using Putty/SCP (see my other response to this question below) to connect to an TFTP/SSH server running in Bash.
What about using winscp to access your files through a putty terminal I am working on an Apache site and having lots of trouble displaying an HTML background in a page on my Apache site even though other portions of the page enabled with SSI work I’m wondering if it’s because we’re using a Windows tool to modify Linux files
That should work fine – your Apache site shouldn’t care what you’re running to create your files.
Wow … how does a limitation like that get through a design review? Samba has done this for years without (much) issue so why is it such a showstopper for a Microsoft created product?
Because this isn’t a supported mechanism for accessing files via a networked file access protocol; it’s what happens when a hacker modifies files stored in a hidden system folder.
This seems like one of those things where you could prevent 90% o problems for people by making the install less stupid. (ie. On install create a soft link from the root of the linux home to the roo of the windows home.)
Hmmm, if only we’d thought LONG and HARD about such issues
Take, for example, your suggestion:
If we pointed ~/ in Bash into %HOMEDRIVE%%HOMEPATH%, then the Linux tools would break because they wouldn’t be able to understand Windows paths, and settings. Worse, they may try to overwrite Windows settings with Linux settings, breaking the tool when run in Windows.
What if you made NTFS Unix friendly instead of this workaround?
This isn’t a limitation of NTFS – it’s an issue due to the philosophical and architectural differences between Windows and UNIX.
Thank you Rich for your work,
I think it is worth noticing that you can link windows files/dir into wsl (I’ve added this to my ~/.bashrc):
DROPBOXHOME=”/mnt/e/Dropbox”
test -f $DROPBOXHOME/bash/.bash_aliases && ln -nfs $DROPBOXHOME/bash/.bash_aliases ~/.bash_aliases && . ~/.bash_aliases
Hey Constantin. Thanks for the suggestion, but please take great care and check that DropBox persists files’ extended properties when copying them otherwise, if your files’ extended properties deleted or not persisted correctly, you could still end up with a corrupted Linux filesystem.
What is the suggested process of backing up any files in the user’s home folder?
Usually people using bash configure it to their hearts content, but when I need to wipe drive C, or reinstall Windows, how can I make sure I won’t lose my settings?
Great Q Frank:
We suggest that from within Bash, you copy/move your Linux files to folder(s) in your C: / D: / etc. fixed drives. From there you can copy them wherever you like. When it comes time to restore: Open Bash and copy your Linux files back into your new, clean Linux filesystem.
Any plan on supporting ext2/3/4 natively in Windows?
No plans right now, but its a popular ask: Please upvote here: https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13818042-support-mounting-xfs-ext2-ext3-ext4-etc-partition
Given that there’s a real possibility of someone causing an issue here, would it not be wise to provide tools that allow people to work with the lxss permissions? This would allow people to at least fix their issues themselves, rather than leaving the file in an unusable state.
For example:
lxperm /check {path}
lxperm /list {path}
lxperm /set {path} /perms 0777 /uid 1000 /gid 1001
Perhaps, but at the cost of leaving several important developer tools unsupported. We believe it’s FAR more valuable to the community to invest our finite resources in getting more tools and apps running well, than trying to fix an issue that, for now at least, can be dealth with by advising users not to monkey around with hidden system files in the manner described in this post, etc.
‘Finite resources’? You do realise how much ‘resources’ Microsoft has right? I develop OSes in my spare time and I know it can be difficult to integrate new features and merge philosophies but if I can make an OS that runs ELF/PE binaries and uses ext2/3/4 and NTFS filesystems on little and big-endian systems. THEN WHY CAN’T THE POWERFUL GOD OF THE PC!
Uhhh … you think Microsoft just has this random pool of people that one can walk up to and say “you, you, and you … my office … 5 mins … and bring a laptop”?
Of course not.
Microsoft like most successful businesses runs a pretty tight ship. If you’re interested in making this thing better, we’re always looking for smart, talented, driven new team members!
Also, I know it may be a different idea but Linux has had Windows program compatibility for a while now. WINE is an application compatibility layer for Linux and I have been using it for a long time to run Windows-only programs such as IMVU. Why is it that Linux can do what Windows can’t, and yet Windows can’t because of “Design” or “Philosophy” differences. I call BS. -Drops mic-
Might want to pick your mic up and make sure you’ve not broken it
Linux has had some amount of Windows app compat, yes. So has Windows over the years, but the approach we’ve taken with WSL is far, FAR more stable and resilient.
Note that WSL is pretty new – it’s only about 18 months old at this point! I am pretty sure that given time, we can solve the VAST majority of the issues and limitations currently present.
I mounted a virtual disk(vhdx file) as a drive with NTFS format in windows, it still has no metadata in my bash on windows.
A ls command will cause “ls: cannot access $RECYCLE.BIN: Permission denied”
Yeah. We haven’t yet built support for mounting VHD’s or other forms of removable media. If you would like to see this happen though, be sure to upvote here as appropriate: https://wpdev.uservoice.com/forums/266908-command-prompt?query=mount
Rich, may I say you are handling these replies with consideration and tact. Well done, sir.
LOL
Thanks Ryan 
I am not accustomed to defending Micro-Soft, but here goes. I am surprised and disappointed that so many people are flaming in response to a sensible warning, and are protesting that beta software is not perfect. Beta releases exist to help find, understand, and resolve problems. I am glad that the software exists, and hope it fills a need.
Thanks Graham – appreciate your support.
One small nit though, It hasn’t been Micro-Soft for over 35 years
Second that. Such restraint
I haven’t used WSL but have read a lot about it. The guidance isn’t trying to make things crippled. I’d ask those commenting to actually understand how NTFS works, how Linux works and then try to actually reason about the problem in their head before flaming. Crazy.
The approach WSL uses to store extra metadata sounds similar to the “mark of the web” NTFS stream that’s saved alongside files downloaded from untrusted sources. Works well (although I personally disable it via group policy).
It’s admirable that MS have gone this far and continue to push on with improvements to WSL.
Saying “improve NTFS support in Linux” doesn’t help. You can’t have two OS’s being in charge of a single file system.
I guess MS could have stored the Linux data in some single file – like a VHDX – rather than as files within a hidden system folder. That would give similar functionality and make the need for this post moot.
you can run the command dos2unix on files edited in Windows to make them compatible on Linux. If it’s not already installed, you can use yum or apt-get on most distributions to install
No you cannot because this just changes the line endings from CRLF to LF, but doesn’t help with the issue that the extended attributes are gone and the file isn’t even visible in Linux. We are not talking about making the file *contents* compatible, but the file *metadata*.
I would agree with you that its best to stay native wherever possible.
Its not so uncommon for a support technician to get sent an ASCII config file from a customer as eg. an email attachment from a *nix environment and need to check and/or change it before returning it.
This can be done with Notepad++ by selecting the options “view” => “show symbol” => “show end of line” and “show all characters” , followed by “Edit” => “EOL Conversion” => and then switch from *nix to windows.
Then you can edit the file , and when you are done convert EOL back again.
Its fiddly and annoying but sometimes the easiest way to get the job done without remote access to the system where the file will be used. Or am I missing the point here?
Thanks for the information and for replying to all the comments even when they are completely off topic and inappropriate!
Thanks
Thanks for sharing this information. I’m enjoying what I’m seeing so far and these are pretty exciting times.
Depends on how you run bash on windows. Cygwin can be configured to preserve the files line endings IIRC. I didn’t see which bash for windows implementation you are referring to.
I usually use notepadd++ for editing files used by both environments. Its a great editor and preserves your line endings, file name case, etc.
Most modern editors do a good job of handling line endings sanely. I regularly use VSCode, Visual Studio, Vim, Sublime, Notepad++ and all work fine.
I have found that using Ultra Edit, WinSCP or some other ftp mechanism works best. This ensure that you don’t accidently open a Linux file the wrong way.
Having a feeling VSCode would work.
Thanks for the reminder! Having used Msys / MinGW for years you learn to be careful – they do try to set meta data like executable but it often bites you when sharing files with a Linux VM.
And then there’s still EOL fun and games, especially when using Git defaults. At least Text mode problems have pretty much vanished.
Oh, and MAX_PATH still gets in the way on the windows side.
What fun
Yeah, there are always going to be issues and compromises when welding two similar but different things together.
MAX_PATH work continues for Win10 CU – should have news about that coming soon
I find this limitation very confusing and frustrating. So it is impossible to copy import files into this fake virtualized file-system?
How do we download/copy (from the web browser) into this wacky file system for further installation processing.
For example (in order to install jekyl I need to install a newer copy of ruby so how do I get my downloaded rub.gz into
my in-accessible and therefore in-usable fake file system ?????
Use Linux tools to download it, and you have no problems. Alternatively, download into Windows space, and use Linux cp to copy from Windows space to Linux space, and you have no problems.
The man explains this ten times and you just don’t get it.
From within bash you can access any folder on you computer!!!!!
You can copy any files you like into your Linux filesystem via ssh to a remote machine, or from your fixed Windows drives via /mnt//…
The guidance here is to NOT copy files into the %localappdata%\lxss folder using Windows File Explorer or apps.
Thanks very much for this writeup and warning, Rich – it explains how I corrupted my own WSL setup a few months back – I just came to the conclusion that writing to the lxss filesystem didn’t work yet, and that’s pretty much right.
Here’s a question for you, though: Given the current state of things, how *should* we back up (and more importantly, restore) files that are created/modified from within the lxss filesystem space? (I suppose creating a cpio archive or tarball on an NTFS filesysem (but using the WSL environment tools) should work, and then restoring from that should be safe (as the restore should recreate the req’d metadata), but I was wondering if there’s any safe way to backup & restore the lxss environment (or a portion of it, say ~home) from standard Win10 backup tools, since at the least, this could mess with dates for directories and such…)
Sorry to hear you bumped into this issue. Rest assured we’re working to figure out a sane solution – bear with us!
I would recommend using a Linux file sync/backup tool. I know that Borg BackupBorg Backup was looking to testing out on WSL recently: https://twitter.com/ahut10/status/808735150859132928
Thanks for the work on this, and I’m sad to see the rude people in the comments.
However, I am curious and will try to ask more nicely:
Is there any roadmap or timeframe for natively mapping the POSIX-NTFS file metadata, so that this is a non-issue, or less of an issue?
Thanks!
— Chad
Thanks Chad.
We are looking at this filesystem metadata interop issue very closely. We’ve already identified several key improvements we can make and have discussed with the NTFS & filesystem team. However, that work cannot fit into the Win10 Creator Update schedule so it’ll be worked on during the subsequent release(s).
We’ll share more on this as we get a well thought-out plan
Hey Rich, not sure why folks are flaming you so hard about this, I think you guys are doing a wonderful job, and I’m extremely impressed with the progress Microsoft has made with WSL. I’m working with it now, evaluating whether I can switch my whole dev team from Macs to Windows because of this. I just got bit, apparently, by the issue you’re describing – I decided to set up a project in /home/…/source/project that lives in AppData instead of on the windows main file system, and now have a bunch of files that can’t be deleted or modified, even by sudo or from explorer running as admin – I just get the Access Denied, or ‘can’t enumerate objects’ when I attempt to change permissions or anything on them. So I agree – doing this will definitely ruin your day.
Thanks for the feedback Clay and sorry you got bitten by this issue.
We’re definitely keen to see if we can smooth this problem out in the future, but until then do avoid making any changes to files and folders under %localappdata%\lxss.
Can you move your Mac users over to Windows & Bash? Only you can tell that: I suggest starting with a couple of willing guinea-pigs and have them try to work alongside their colleagues. There is likely to be some work involved in making this work, esp. with Mac being based on *BSD and with its own idiosyncrasies, but taking others’ experiences into account, it should not require herculean effort.
Ping me on Twitter (https://twitter.com/richturn_ms) to let me know how you get on – be fascinated to hear how it goes.
What about making something like a minifilter driver to automatically add/modify the file EA when accessing through windows?
Such a minifilter only solves some of the issues; we need a more comprehensive solution: Working on it
What about a Property Shell Extention that will add the capability (only in dev mode) to set those missing data (ADS I presume) from the Windows side ?
This won’t work as a comprehensive solution; for example, what happens as soon as one edits the file again and the Linux permissions, size, and timestamps get deleted again? You won’t want to try to fix each file individually.
How does this SQUARE with
0:09:49 of [Running Bash on Ubuntu on Windows! – Mar 30, 2016 at 12:47PM by Russ Alexander, Rich Turner ]
(https://channel9.msdn.com/Events/Build/2016/P488?ocid=player),
where they use Visual Studio Code to modify stuff on the bash side?
You can modify files in the Windows filesystem using Windows tools, e.g. changing a file in your node based website at c:\dev\MyNodeSite\server.js, and run/serve that website using node running in bash by calling:
$ node /mnt/c/dev/MyNodeSite/server.js
As the article above clearly states, however, don’t modify any files under the Linux filesystem located under %localappdata%\lxss using Windows apps or tools – only change these files from within Bash.
In WSL, Bash command sftp won’t seem to recognize local storage of WSL pwd and lpwd show the samething on the remote ftp and using lcd /mnt lcd /mnt/c return an error or non local PC system, any idea what wrong?
Sorry, can you share a repro – not quite sure how to reproduce your issue.
Can i control the location of lxss?
For files in lxss and outside of /mnt, developers ultimately need UI application access. Is XWindows support coming?
We’re keen to smooth-out the gap between the Linux filesystem and the Windows filesystem, and will be looking into potential improvements here for a future OS release.
We’re not focusing effort on X/GUI support at this time: we are using all our resources to deliver an awesome developer command-line environment for now. That said, we’re not doing anything to block X/GUI apps from running, as many have found and enjoy, but we’re not prioritizing X/GUI support at this point.
Hi there.
Thank you for this awesome tool.
I have got a question. I am a php developer and I use windows. I have been using vagrant for years now. I use vagrant because I can work on www folders from my windows applications such as Sublime Text. I can just go into my E:/Projects/www/wordpress.dev (E:/Projects/www is basicaly /var/www in my vagrant virtual ubuntu) and edit any file or just copy and paste a picture etc… How can I do this with WSL? I tried to create a virtual host with apache2 on WSL and point www folder to my /mnt/e/Projects/www folder. but when I create a file from windows, linux doesn’t see those files.
Thanks.
Hey Erdem: Are you running Win 10 Anniversary Update? If so, you will likely need to restart Apache after adding a new file since Win10 AU doesn’t support inotify.
Thanks for the warning (found out the hard way).
Shouldn’t maintaining metadata be handled by the underlying OS? Your sentence “Windows apps do not know how to (nor that they should) re-calculate & persist this Linux metadata” implies that it’s the responsibility of individual apps writing to a file to manage file metadata, seems surprising to me, I would have expected you to say “Windows does not (YET) know how to re-calculate & persist this Linux metadata”.
It is the job of the OS & filesystem to keep file metadata up to date. However, writing Linux file metadata for each and every file access by every Windows process is a significant overhead, esp. when the vast majority of those files will never be accessed by a Linux tool. Even moreso knowing that Linux files are updated each time they’re accessed (i.e. read) too!
Thanks for the note though: I’ve updated that part of the post accordingly (attribution in update note).
Thank you
Just to clarify, I didn’t think that windows should add linux metadata to all files. I was thinking that windows can be made smart enough to do this only for files in the lxss folder.
But what if a user decides to chmod a file somewhere under //mnt/c/dev/wherever, for example?
FWIW, If you fix the linking problems, you could then by default just link each linux user’s /home/Linuxusername to something like c:\Users\Winusername\linuxhome\Linuxusername. (you might need a special linuxhome Winusername account to avoid Win ownership problems…) Doing this would let users use Windows tools to their heart’s content at least within their home directories, so the problem would only rear its ugly head when trying to use Windows tools to edit stuff elsewhere like /etc. I expect this would eliminate the problem entirely for the vast majority of users and use cases.
You do NOT want us to do that – believe me! If we did, your *NIX tools config files for Git, Vim, etc. would then overwrite the same config files for Git & Vim etc. on Windows.
necro post, but… it sounds like he’s referring to creating a subfolder within the user’s windows home folder, and storing the contents of ~ there.
something like e.g. C:\Users\Ash\WSLHome\
Hi. It is possible move lxss elsewhere and use a junction of it in %localappdata%\ so that I can preserve my distro in case of Windows reinstall?
Thank you
We strongly encourage you NOT to do this for a variety of reasons that could easily result in file corruption, installation issues, upgrade issues, etc.
We do, however, encourage you to backup your most important data regularly. There are various ways of doing this, but essentially we recommend regularly copying essential files from your Bash environment to a Windows-accessible location and archiving that content to offline storage, or perhaps copying files to a remote machine via rsync, or zipping important files in bash and copying the zip’s off to OneDrive/DropBox/other-online-storage-mechanism.
Just be sure NOT to try to backup files under %localappdata%/lxss using Windows backup tools for the reasons given above.
I’m wondering, is this limitation new in the creators update of WSL? It seems to me that I could modify Linux text files from windows with the version in Anniversary Update. Did I dream it?
No – you CAN reach into the Linux filesystem and change files in AU and CU using Windows apps (e.g. Notepad). But if you do, know that there’s a very good chance you’ll end up with corrupted files and/or data loss.
This question I can’t really get an answer to, and I am really curious about it.. Since there’s WSL, and has the same capabilities as Ubuntu from what I see so far, is it possible to turn this into an area for working on AOSP related things or would that not be advisable/why?
You should have more success using WSL to build & deploying AOSP to devices by running the most recent Win10 Insiders Builds. But you cannot run AOSP atop WSL – that requires a whole load of UI & graphics infrastructure that WSL doesn’t contain.
I learned this the hard way after backing up my entire Users folder before reinstalling Windows; I had no idea at the time what lxss even was and when that folder was put back, I got some fun input/output errors trying to install the subsystem again.
So if I install git on WSL and then clone a repo from GitHub should I not edit those files in Windows with Visual Studio?
If you clone your project into a folder under the Windows filesystem, e.g. `/mnt/c/dev/projects/`, you’ll be able to edit using Windows tools, and edit/build/run/test using *NIX tools.
Hi Rich,
Thanks for the confirmation. I thought initially that I couldn’t a file at all (on the whole disk) with Windows if the file was created with WSL.
This is cool, I wish I knew that before.
Can i move my Ubuntu system to a new location (move %localappdata%\lxss\ folder to another location).
oh ok! i just read about it in comment section
No. We’re aiming to allow you to install distro’s via the Windows store app, to other fixed drives on your machine if you wish.
Well they say whatever can go wrong, will go wrong… If I understand correctly, when some intrusive access from global tool (like desktop.ini from explorer) happens to generate a file, it fails the integrity of Linux filesystem. Hopefully not in a catastrophic way though.
Anyway, just a quick couple of question.
1. What’s behind the design decision of putting Linux filesystem in NTFS?
At a glance it seems much easier to just make a partition image of ext4 like how virtualization apps approach this: make LXSS mount that as VolFs, and Windows tools having access to them with either separate mount with drive letter (like how NFS and Samba mount does) or some kind of UNC format. Aside from the capacity problem, it seems to avoid all those metadata problem, self-contained, and easy to integrate with existing Linux partition devices with ext4.
2. Where is that metadata DB stored?
Is it in local? Or as a special ACL in NTFS? For example, if we try to chmod the mounted USB drive, would it be conserved in other machine (in native Windows, WSL and even Ubuntu)? If it is accessible, then it might be a way to implement a WSL-aware windows tools.
I refer you to our consolidated WSL learning page, and specifically the post & video covering the WSL filesystem infrastructure.
This is exactaly what I has looking for. Congratulation!
i have the exact opposite issue… i tried to move/modify a file on a windows system with hardware that was running a form of linux. now windows thinks the files are directories and it won’t allow me to delete them. all i can do is change the name and that doesn’t help. when i try to delete i get the message ‘invalid directory name’.
anyone know of a way to fix these files so i can get rid of them?
these files are on a WD My Book USB drive formatted as NTFS
I don’t quite follow. Let me see if I can re-state your scenario: You moved some files onto an NTFS formatted USB drive using a Linux PC, and now those files are inaccessible.
If so …
I don’t know what NTFS driver you were running on your Linux PC, but there’s a chance that it damaged the files in some way and didn’t write the NTFS data correctly. It’s also possible that the filename contains characters that are permitted by Linux, but not by NT.
You might consider mounting the USB drive using WSL, and then renaming those files using just ASCII characters and seeing if Windows can access those files once more.
I don’t care what any of these haters say. This TOTALLY kicks butt!
I was using VS2017 Linux Makefile projects against my Linux box and samba (cifs) was a pain. Now I can do it all in one place (assuming I follow a couple of simple rules).
Even x11 forwarding (howbeit unsupported) works well for me!
Thank you Rich (and team)! Nice work!
I can’t wait to see whats next!
LOL
Many thanks Señor, glad our work isn’t entirely in vain 
Lots more great stuff in the pipe. The release or two beyond Fall Creators Update will also be fun-packed releases 
Thanks for this great write up. I would like to make sure I understand everything correctly.
Lets say I want to start a new Ruby on Rails project on my windows 10 computer. I want to install ruby/rails and the database on Linux however I want to use something like visual studio code instead of vim to edit the project files.
After I’m done installing everything everything (within Linux) I should generate the new rails project within bash at the /mnt/c/dev/projects directory. In this way the files will be stored on the windows file system. Then I can open up Visual Studio Code on windows in my C:\dev\projects\railsapp directory. From here I can use VSCODE like normal and modify the ruby files till my heart is content with near fear of issues/data loss.
The rails server running on Linux will see the modifications made from windows/VSCODE and I will see those changes reflected on localhost.
Is my understanding correct? Would the described situation work? I’m really happy for Ubuntu on Windows 10 this would make me even happier.
Yes. Precisely
Thanks for taking the time to respond to all the comments and mine. This is an amazing feature of windows!
This feature alone is what drove me to choose windows over mac.
I am a proud PC user — first, because of this feature and second because of everything else!!
Microsoft, please keep evolving this feature and you will have me for life!!
Glad you’re digging our work
Lots more on the way in future releases too! 
Can I enable Bash on Windows 10 Enterprise?
Absolutely. The only SKU’s we don’t currently ship in are LTSB, but now that WSL is no longer a Beta feature, it’s highly likely we’ll be in the next LTSB release after FCU.
First thank you Rich for dropping by Ask Ubuntu and updating us on WSL differences from cygwin. I’ve been studying WSL videos last 24 hours and am looking to install it when new Win 10 laptop arrives next week.
As far as this thread is concerned, is it possible to setup bash.exe as a super user that owns %localappdata%\lxss\ within NT’s security system? Then only “descendants” of bash.exe can read/write/execute there? Would this stop you from touching this directory from win apps unless the bash.exe password was entered?
Glad you’re enjoying the content over here
The issue here isn’t really permissions – we’ve already got that working pretty well.
The problem is the fact that Windows doesn’t know we’re maintaining per-file and per-folder Linux filesystem metadata.
The real solution here is for us to work with the filesystem team, and to ensure Windows understands, and persists any metadata we maintain when moving/modifying files, and for us to better manage our caching layer, etc. We’re working on these and other important improvements for future releases of Windows.
Do keep the feedback coming though, we really appreciate it!
I have a question – I once upon a time I installed Anaconda (python) an my Laptop, afterwards the bash system. Everything worked well.
For some days I updated Anaconda (python3) via Windows which ends up in a mess and I have to un/reinstall Anaconda(python) for the user.
The problem Windwos + Python works but in Linux it does not find the packages like numpy etc. (I think this could be because of wrong paths e.g. – I found no way to “synchronise the systems”.) My brute force solution will be un/reinstalling Windwos 10s Ubutun Bash Shell.
My question know – as far as I know I never create/save some files via Linux – is there a danger regarding my datasets stored under PS C:\Users\XXXX\?
I looked for an answer but nothing-definitive answer my question.
You should treat the Windows and Linux environments like separate environments which can invoke operations from one in another.
If you install Anaconda/Python on Windows, maintain it from Windows. If you install Python/Anaconda in a Linux distro, maintain it from that distro.
You **CAN** invoke commands from one environment via another similar to this:
C:\> bash.exe -c "lsb_release -a"
...
Or
$ cmd.exe /C dir c:\\
...
And you can use commands in this way to tell Windows to do something in Python from within a Linux shell/script, but understand that you’re driving a Windows exe in this case.
Good Morning, Rich;
I had wsl installed when I 1st moved to Anniversary Update… when I updated to Fall Creator’s on Tuesday I ‘reinstalled’ (I thought) Ubuntu from the store to get it to 16.04. What seems to have happened is I now have both 14.04 and 16.04 installed. How do I remove 14.04 without messing up 16.04? (This may be the wrong place to ask this but I can’t seem to find another that pertains to my question. If there is could you forward it and let me know? Thanks!)
Uninstall your legacy distro using `lxrun /uninstall /full` as always
which security based linux distro will work on this .
debian based backtrack tools to install via repos & services.lst
We’re working with several distro vendors as I type. Stay tuned
In Win 10 FCU, I cannot seem to find the %localappdata%\lxss\ path. Not under Local or anywhere. Has this changed now?
I just found it out to be here in Win 10 FCU “C:\Windows\System32\lxss”. Can you please confirm on this change? Why was it moved out of AppData/Local and to System32?
Where are the Linux files stored in Win 10 FCU? I cannot see them at “C:\Windows\System32\lxss”.
In FCU, we now support installing one or more distros from the store. They each need their own folders, settings, etc., most of which is already provided by the APPX infrastructure which governs where files are installed to.
But as I keep saying: PLEASE DO NOT SPELUNK AROUND IN THE LINUX FILESYSTEM FROM WITHIN WINDOWS: https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-not-change-linux-files-using-windows-apps-and-tools/
If you do, you’re VERY likely to experience data loss and/or corruption.
Is this still an issue as of the April 2018 Update (1803.17134)?
Yes. When we (finally) deliver the ability to browse and access your Linux filesystems from Windows, we’ll update this post with a header pointing at the new announcement and guidance. Until then, don’t spelunk into the Linux filesystem folders – bad things will happen!