Do not change Linux files using Windows apps and tools
Update – May 2019 Windows 10 version 1903 has now been released and allows an important update to WSL that allows Windows applications and tools to access Linux files directly. To do this, WSL hosts a new 9P fileserver, which exposes distro filesystems to Windows apps and tools via
\\wsl$\<DistroName>\! You can read all about the feature in the blog post “What’s new for WSL in Windows 10 version 1903“.
The post below contains the original guidance, which also remains true: DO NOT access the Linux files inside of your
%LOCALAPPDATA%folder, since you should only be accessing them . If you’d like to learn more about why you shouldn’t go digging through the Appdata folder for your Linux files, please read on!
There is one hard-and-fast rule when it comes to WSL on Windows:
DO NOT, under ANY circumstances, access, create, and/or modify Linux files inside of your `%LOCALAPPDATA%` folder 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 in your Appdata folder 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!
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
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 three 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 access / create / modify files in your Linux distros’ filesystems from Windows apps, tools, scripts or consoles using
DO NOT access / create / modify files in your Linux distros’ filesystems from Windows apps, tools, scripts or consoles by finding the files in Appdata
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!!
- [2017-03-14] – Updated “Why is this”; thanks to @mn in comments
- [2019-01-15] – Minor updates & improvements
- Last Updated: [2019-05-29] – Added an edit to the top of the post to describe the new feature allowing users to access Linux files from Windows
Just did this unfortunately ):
Better user experiences…
1) Don’t let it be possible
2) Make it do the right thing
A real easy trap to fall into sadly.
Thank you for spelling out this issue. I ran into everything described in this article while trying to troubleshoot some Node issues. I was very annoyed by how “hidden” the files system was and only made things worse by trying to troubleshoot things normally.
The safety issues and “What not to do” should be the first things covered with Windows Subsystem for Linux so we can use the software safely. The differences in filesystems should be explained also. This is the only documentation I’ve come across after trying to troubleshoot things for a month. I was going the “throw in the towel” by the end of the week, but this article has helped me out a lot. I’ll have to start over on purpose now, and you’ve given me the understanding I needed to do so with awareness. Thank you Rich Turner.
Sorry you bumped into this issue William.
We strongly encourage you to run the most recent Windows releases possible in order to take advantage of WSLs rapidly improving features – WSL is a fast moving feature set and receives regular updates throughout its development.
Key among WSL’s improvements in the Spring 2019 release was the ability to reach into your Linux distros’ filesystems from Windows via the \wsl$... path.
This feature was first announced in this post: https://devblogs.microsoft.com/commandline/whats-new-for-wsl-in-windows-10-version-1903/.
And if you’re interested, take a look at this post and video for details of the internals: https://devblogs.microsoft.com/commandline/a-deep-dive-into-how-wsl-allows-windows-to-access-linux-files/.
Inside WSL’s file
The Update of May 2019 says:
“The post below contains the original guidance, which also remains true: DO NOT access the Linux files inside of your %LOCALAPPDATA% folder, since you should only be accessing them .”
I think something .
“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// (e.g. /mnt/c/dev/project/…),”
The situation is better than it was several years ago when I experimented with Windows Subsystem for Unix, but it still has problems. For example if you really create a directory named /mnt/c/dev/project/… where that lowest level directory name is three periods, Windows File Explorer and PowerShell get confused.
I haven’t experimented yet with users named O’Connor or 阿部 but I wonder if Microsoft did.