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
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.
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
- 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!!
[2017-03-14 – Updated “Why is this”; thanks to @mn in comments]