Creating nested directories from Windows in WSL file system creates 'limbo' directories

[RickStrahl]

I'm trying to access the WSL file system from a Windows application by creating folders and files inside of a WSL folder paths accessed via UNC pathing. I seem to be able to create files, but when I create folders the folder don't appear to be visible to Windows or WSL (via VS Code Remote browsing). Further Windows Directory.Exists() reports that a folder exists when I can't actually see it anyway I look at the actual location.

The specific use case here is that I'm accessing a Jekyll installation in WSL at:

/usr/projects/testsite

Inside of my application I use a path like this to get to the folder:

\\wsl$\Ubuntu\usr\projects\testsite

The application basically creates a file in a pre-existing folder for a post (in _posts) which appears to work. I can create the new file and I can see the file in Windows and also the WSL remote in VS Code.

The application also creates a new folder and copies several files into that folder. The Folder structure is something like assets/2020-05-28-posttitle. It creates the folder and then copies post images into this folder.

When I run the code that creates the directory via:

Directory.Create(@"\\wsl$\Ubuntu\usr\projects\testsite\assets\2020-05-28-posttitle");

the command works. However, I can't see the files in the folder via Windows Explorer or VS Code remote. Explicitly navigating to that folder inside of WSL via:

cd /usr/projects/testsite/assets/2020-05-28-posttitle`

fails. I can navigate as far as the assets folder, but the subfolder is not listed.

However, if do the following inside of my code:

Directory.Exists(@"\\wsl$\Ubuntu\usr\projects\testsite\assets\2020-05-28-posttitle");

the call returns true.

One thing to note is that the Directory.Create() call may be creating both the assets folder as well as the post specific folder in a single command. This works fine in Windows, but I wonder if there's perhaps something happening here that's breaking the WSL folder creation, since the first part the assets folder appears to be created.

Windows Version: Microsoft Windows [Version 10.0.19041.264]
.NET Version: Full Framework 4.7.2

[therealkenc]

You could go with a tight dotnet repro but I'm skeptical you'll get a lot of eyeballs. Better fighting chance with some CMD or Powershell CLI steps.

As an initial matter you are creating the directory under /usr, and your default WSL user doesn't have permissions there. If you've made your default user root, don't. If you've made the permissions to /usr/assets 777, that should work but you are better off working in /home/you (at least in the repro) for sanity.

[RickStrahl]

I'm replicating a user scenario, but I don't think that the /usr issue is permissions. Install is stock WSL - standard user, no changes to profiles etc. so not running as root by default.

As I mentioned the file that is created works as expected every time - it's created and updated. it's the directory related stuff that's failing.

When I get a minute I'll see if I can create a simple repro scenario and perhaps set it up as a powershell script. It's possible though the problem isn't in WSL but in the .NET bits and how its creating the directories. Because it sure looks like the folder is there but it's just not visible (tried ls -a but still no joy).

Just to be sure I re-created the Jekyll site in /home/projects/testsite and the results are the same.

[therealkenc]

[cross-post on your edit]

I don't think that the /usr issue is permissions

Me either; but it fast-forwards one reply post in a hypothetical repro (dotnet, powershell, or otherwise) [we've done that part now]

It's possible though the problem isn't in WSL but in the .NET bits

Anything possible. Heads up ref #4064. Although I don't think it is that either, and that issue has gone sideways.

A ten-liner dotnet app will probably get a "confirmed here" out of me if you post it. A PS CLI is better, but alas I bet you can't repro it with simple commands.

Thing is, skeptical it is "in the .NET bits" either. But a repro is the place to start.

[RickStrahl]

Ok so I started pinning this down and it turns out this was definitely operator error on my part. The path I used was chopped missing a leading slash resulting in the mis-handled operation. Notice the WSL path in the screen shot - it's missing the leading \ but because of the C style syntax my mind just accepted it as \\wsl$\.... 🤦

With the fixed path in place I was able to create and update folders in WSL from Windows without any issues, which is great to see that that works... I was unaware that this actually worked with non-Windows mounted paths. Part of this discussion initially started as a question whether this was even a supported scenario and in fact I had something in my docs that mentioned that this wouldn't work - which I can remove now since it does work. Yay!

This is really great integration work!