Handle 8.3 paths does not work

[Debee416]

How to reproduce from console:

rem create file "VeryLongFileName.txt" in directory "C:\Test\Source\SomethingVeryLong\AnotherLongDirectoryName_1.0.0_Beta1.10\data" 
echo blah>C:\Test\Source\SomethingVeryLong\AnotherLongDirectoryName_1.0.0_Beta1.10\data\VeryLongFileName.txt
rem start projection
SimpleProviderManaged.exe --sourceroot C:\Test\Source\SomethingVeryLong\AnotherLongDirectoryName_1.0.0_Beta1.10\data --virtroot C:\Test\SomethingVeryLong\AnotherLongDirectoryName_1.0.0_Beta1.10\data

from another console:
rmdir /s /q C:\Test\SomethingVeryLong

expected result: directory "C:\Test\SomethingVeryLong" is removed
actual result: C:\Test\SomethingVeryLong\ANOTHE~1.10\data\VeryLongFileName.txt - The provider that supports file system virtualization is temporarily unavailable.

[Debee416]

There is a hotfix: "fsutil.exe behavior set disable8dot3 1"

but out customer needs 8.3 paths due some legacy software :(

[cgallred]

I'm not able to reproduce this issue. What version of Windows is this?

[Debee416]

Please try "fsutil.exe behavior set disable8dot3 0" before creating directory C:\Test\

rmdir /s /q C:\Test
fsutil.exe behavior set disable8dot3 0
mkdir C:\Test\Source\SomethingVeryLong\AnotherLongDirectoryName_1.0.0_Beta1.10\data
echo blah>C:\Test\Source\SomethingVeryLong\AnotherLongDirectoryName_1.0.0_Beta1.10\data\VeryLongFileName.txt
SimpleProviderManaged.exe --sourceroot C:\Test\Source\SomethingVeryLong\AnotherLongDirectoryName_1.0.0_Beta1.10\data --virtroot C:\Test\SomethingVeryLong\AnotherLongDirectoryName_1.0.0_Beta1.10\data

from another console:
rmdir /s /q C:\Test\SomethingVeryLong

[cgallred]

I did try the repro on a volume with short names enabled. This looks like a bug that is fixed in Windows build 18973 and above. Can you try to reproduce it on Windows 10 Version 2004 (i.e. May 2020 Update)? You could also try it on a recent Insiders build.

[Debee416]

Ok, thanks. I will try on Version 2004. Right now there is some problem with Windows Update on my machine, probably caused by ProjFs.
0x80070171 can be googled as ERROR_FILE_SYSTEM_VIRTUALIZATION_UNAVAILABLE

[cgallred]

Windows Update doesn't use ProjFS, so that error is certainly unexpected. The only way I can think of for that to happen is if somehow a virtualization root was created in a directory that Windows Update wants to use, and the provider for that virtualization root is no longer running. The system never does that, so something else would have to have done it.

In your experiments did you happen to set up a virtualization root in the %TEMP% directory or under some other directory that you didn't create yourself?

[Debee416]

Eh, that is embarrassing. I set c:\ as virtualization root by accident.

Found it in Procmon, it shows "The provider that supports file system virtualization is temporarily unavailable" as Result 0xC000CE01.

Is there any way out of it?

[cgallred]

You should be able to fix it with fsutil reparsePoint delete c:\ as Adminstrator.

[Debee416]

Nope :(

[cgallred]

Ah right, once again I'm thinking of more recent platform behavior. That approach should work starting with build 18876.

For your build, try unloading the ProjFS filter before doing it. First make sure you have no running virtualization instances on the system, otherwise the first command below will hang until they're stopped. Then as Administrator:

1. sc.exe stop prjflt
2. fsutil reparsePoint delete c:\
3. sc.exe start prjflt

[Debee416]

Reparse point removed, May Update installed and rmdir with 8.3 paths is now working. Thanks a lot!