1

Rarely (but sometimes) I encounter the following problem: WSL and the Windows see different files.

I had a directory called foo on drive D. I removed it from Windows, then some strange things happened. The directory becomes invisible, and un-deletable, but I can enter it in WSL!

home:/mnt/d$ ll
total 0
drwxrwxrwx 1 user user 4096 Oct 31 14:46 ./
drwxrwxrwx 1 user user 4096 Oct 31 14:45 ../
drwxrwxrwx 1 user user 4096 May  2 08:59 bar/
home:/mnt/d$ rm foo
rm: cannot remove 'foo': Is a directory
home:/mnt/d$ rm -rf foo
home:/mnt/d$ rm -rf foo
home:/mnt/d$ cd foo
home:/mnt/d/foo$ ll
total 0
drwxrwxrwx 1 user user 4096 Oct 31 14:46 ./
drwxrwxrwx 1 user user 4096 Oct 31 14:45 ../

I don't know the root-cause.

The only solution is to close all WSL instances, including all background and GUI applications. Then open a new WSL.

Is there any better solution? (I don't want to restart all of my WSLs)

I use:

  • Win 10 Pro
  • Version 10.0.18362 Build 18362
3
  • "The only solution is to close all WSL instance" -- this suggests some program is using that folder.
    – Biswapriyo
    Oct 31, 2019 at 14:15
  • Please specify the version of Windows 10 you are using. If you are using 1903 and/or 1909 then WSL functionality should be stable. However, if you are using an Insider Preview build of 20H1 than WSL 2 functionality can be unstable. 1909 of course is the first version that has WSL 2 functionality.
    – Ramhound
    Oct 31, 2019 at 14:23
  • Edited, added the windows version Oct 31, 2019 at 14:35

1 Answer 1

3

I don't have a fix for the problem, but I can show where it is coming from.

The duality of Windows and Linux, all built on the same set of Windows API, caused Microsoft to make many compromises.

First, since file metadata is different between Linux and Windows, Microsoft decided to store the Linux metadata as a fork inside the file. This means that operations that do not conserve forks will destroy the Linux metadata. For example, all Windows operations that update files by creating a new version will lose the Linux properties of the file.

The golden rule is that Linux files should be manipulated in Linux, and Windows files by Windows. Departing from these rules may cause weird side-effects and inconsistencies.

More information about this may be found in the Microsoft blog
Do not change Linux files using Windows apps and tools.

There had been improvements of this situation in Windows 10 version 1903, as documented in the article Updated WSL in Windows 10 version 1903 lets you access Linux files from Windows. One should still be careful with such operations, testing carefully what works or doesn't at the moment. The following quote from the above article shows that this is an on-going process:

The marriage between Linux and Windows is getting stronger. Having embraced Linux with WSL (Windows Subsystem for Linux), Microsoft is now doing what users have been begging for: Windows 10 April 2019 Update makes it possible to access Linux files from Windows.

The Windows/Linux dichotomy has created a very inefficient structure, where Linux needed to read data from the files in order to access their metadata. The Linux file-system is rather based on Inodes and memory-resident file-tables, without which performance is simply impossible.

Microsoft's solution was to create a virtual file-system for Linux, called VolFs. The mounted Windows disks use DrvFs, which is very similar.

To quote from the Microsoft blog WSL File System Support:

VolFs is used to mount the VFS root directory, using %LocalAppData%\lxss\rootfs as the backing storage.

Since Windows has no related inode concept, VolFs must keep a handle to a Windows file object in an inode. When VFS requests a new inode using the lookup callback, VolFs uses the handle from the parent inode and the name of the child to perform a relative open and get a handle for the new inode. These handles are opened without any read/write access to the files, and can only be used for metadata requests.

When a file is opened, VolFs creates a Linux file object that points to the inode. It also reopens the inode’s file handle with the requested read/write access and stores the new handle in the file object. This handle is then used to satisfy file operations like read and write.

In effect, what happens is that two file-systems exist here in parallel, Windows NTFS and WSL VFS, and coherence is not guaranteed.

Any solution to the problem must come from Microsoft. You should ensure that you are always on the latest build of Windows 10, as Microsoft is still working on these problems.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .