Do not change Linux files using Windows apps and tools


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 Bash on Windows:

DO NOT, under ANY circumstances, create and/or modify Linux files using Windows apps, tools, scripts, consoles, etc.

Also note: 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: 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

Do not create/modify Linux files from Windows apps/tools

Do not create/modify Linux files from Windows apps/tools!

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

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:

  1. DO store files in your Windows filesystem that you want to create/modify using Windows tools AND Linux tools
  2. DO NOT create / modify Linux files from Windows apps, tools, scripts or consoles

Remember: There’s a reason we gave the %localappdata%\lxss\ folder ‘hidden’ & ‘system’ attributes 😉

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.

[2017-03-14 – Updated “Why is this”; thanks to @mn in comments]

Comments (96)

  1. David Windehem says:

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

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

  2. Perlence says:

    Can I still delete Linux files using Windows tools?

    1. Yes. Just be REALLY sure you want to delete them; once they’re gone, they’re gone! 😀

  3. whiskey tango says:

    that old tactical incompatibility rearing it’s head. 😉

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

      1. Creshal says:

        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.

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

        2. Chris Martin says:

          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.

  4. Salvator Gomez says:

    Thanks for shedding some light on this!

  5. Agron Selimaj says:

    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.

    1. “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.

      1. Chris says:

        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.

  6. Jayson Reis says:

    Is it advisable to create a link to that folder pointing to another drive?

    1. $ ln -s /mnt/c/work ~/Work

      Problem Solved

      1. And that is advisable?

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

  7. Harry Campbell says:

    I’m assuming Windows Apps like Putty & WinSCP are exempted from this warning.

    Please advise.

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

  8. Edward D. says:

    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_**

    1. 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 😉

      1. Baywatch says:

        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?

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

  9. N P says:

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

    1. “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.

      1. Creshal says:

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

        1. “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.

  10. CharlieF says:

    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?

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

      1. Seppo Yli-Olli says:

        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.

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

  11. Terran B Rogers says:

    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

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

  12. Terran B Rogers says:

    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

    1. That should work fine – your Apache site shouldn’t care what you’re running to create your files.

  13. Bozo says:

    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?

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

  14. keynan pratt says:

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

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

  15. Yan Minari says:

    What if you made NTFS Unix friendly instead of this workaround?

    1. This isn’t a limitation of NTFS – it’s an issue due to the philosophical and architectural differences between Windows and UNIX.

  16. Constantin Guay says:

    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

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

  17. Frank says:

    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?

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

  18. Edgardo Rossetto says:

    Any plan on supporting ext2/3/4 natively in Windows?

  19. Jamie says:

    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

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

      1. Fedora Croe 24 User says:

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

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

      2. Fedora Core 25 User says:

        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-

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

  20. Lex Chou says:

    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”

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

  21. Ryan says:

    Rich, may I say you are handling these replies with consideration and tact. Well done, sir.

    1. LOL 🙂 Thanks Ryan 🙂 

      1. Graham Bosworth says:

        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.

        1. Thanks Graham – appreciate your support.

          One small nit though, It hasn’t been Micro-Soft for over 35 years 😉

  22. Tom Murphy says:

    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

  23. Adrian says:

    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?

  24. Tom Gagantia says:

    Thanks for the information and for replying to all the comments even when they are completely off topic and inappropriate!

  25. amwales says:

    Thanks for sharing this information. I’m enjoying what I’m seeing so far and these are pretty exciting times.

  26. chuck says:

    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.

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

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

  28. Bond says:

    Having a feeling VSCode would work.

  29. steve lee says:

    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

    1. 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 😀

  30. Stephen Bovy says:

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

    1. John Cowan says:

      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.

    2. crv says:

      The man explains this ten times and you just don’t get it.
      From within bash you can access any folder on you computer!!!!!

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

  31. Dub Dublin says:

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

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

  32. Chad Woolley says:

    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

    1. 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 😉

  33. Clay Gulick says:

    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.

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

  34. Syahmi says:

    What about making something like a minifilter driver to automatically add/modify the file EA when accessing through windows?

    1. Such a minifilter only solves some of the issues; we need a more comprehensive solution: Working on it 😉

  35. TestMan says:

    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 ?

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

  36. Joe Dorocak says:

    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?

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

  37. Alex Vaib says:

    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?

    1. Sorry, can you share a repro – not quite sure how to reproduce your issue.

  38. jeff says:

    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?

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

  39. mn says:

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

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

      1. mn says:

        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.

        1. But what if a user decides to chmod a file somewhere under //mnt/c/dev/wherever, for example?

  40. Dub Dublin says:

    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.

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

Skip to main content