Why is this?

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".

So what SHOULD I do?

To work on files using both Windows and Linux tools, store & work on those files in your Windows filesystem, and access them from both Windows and from Bash 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 create/modify using Windows tools AND Linux tools

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).

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.

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.

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.

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.

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/` 😉

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.

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.

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.

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

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

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.)

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.

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?

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.

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.

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!

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-

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.

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.

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 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…)

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).

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.

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.

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.

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?

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.

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.

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).

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.

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.

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.

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.

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 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!

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.

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?

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.