Do not change Linux files using Windows apps and tools

Avatar

Rich

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 P9
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][1]”.

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:

under ANY circumstances, access, create, and/or
> modify Linux files inside of your 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!

[Do not
 create/modify Linux files from Windows apps/tools][1][2] 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 three rules in order to avoid
losing files, and/or corrupting your data:

  1. DO store files in your Windows filesystem that you want to access/create/modify using Windows tools AND Linux tools
  2. DO access / create / modify files in your Linux distros’ filesystems from Windows apps, tools, scripts or
    consoles using \\wsl$\<DistroName>\
  3. 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][3]. 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][4] 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
  • [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

    [1]:

    What’s new for WSL in Windows 10 version 1903?


    [2]:
    https://devblogs.microsoft.com/wp-content/uploads/sites/33/2019/04/DoNotEnter.png
    [3]: https://en.wikipedia.org/wiki/Extended_file_attributes#Windows_NT
    [4]:
    https://blogs.msdn.microsoft.com/wsl/2016/06/15/wsl-file-system-support/

Avatar
Rich Turner

Sr. Program Manager, Windows Console & Command-Line

Follow Rich   

No Comments.