Can't list directories in WSL2

[mrnerdhair]

Environment

• Windows version: 10.0.19041.508
• Processor architecture: x86_64
• Dokany version: 1.4.0.1000
• Library type (Dokany/FUSE): Dokany

Check List

• I checked my issue doesn't exist yet
• My issue is valid with mirror default sample and not specific to my user-mode driver implementation
• I can always reproduce the issue with the provided description below.
• I have updated Dokany to the latest version and have reboot my computer after.
• I tested one of the last snapshot from appveyor CI

Description

A Dokan-based filesystem mounted into a WSL2 instance returns ENOSYS ("Function not implemented") when attempting to list the contents of a directory. (Note that files and their contents are still accessible.)

This error was discovered while debugging a similar issue with another third-party Windows filesystem, StableBit DrivePool; see here and here for more in-depth analysis.

Logs

mirror.log
driver.log

[Liryna]

@reidrankin Hi!

Are you using the /o option of the mirror?

[mrnerdhair]

No, but I'll test it out real quick... doesn't fix it. (It shouldn't fix it, so that's good.)

[Liryna]

Oh sorry I haven't see the logs and your analysis from the main post.

Indeed FILE_ID_EXTD_DIR_INFORMATION is not supported yet and that disappointing they are not doing a fallback when we return not supported.

Do you have the possibility to build dokan and try to support this structure with the same data of the non extended version? Would be interesting to knoz if that's enough for the system.

[mrnerdhair]

See my second post on that thread :)

[Liryna]

Ah that's again another case where STATUS_INVALID_PARAMETER is a better option to return :)!

We really should one day change all of them.

Would you have the possibility to make small pull request with this change?
Since you did all the work already, having your name as contributor would be awesome!

[mrnerdhair]

(Hold up, you're reading faster than I'm typing! :) I've got the code for the PR ready to go, I'm just filling out the paperwork for posterity.)

[mrnerdhair]

Summary of the analysis on the DrivePool thread mentioned above

This issue is caused by a change in the way WSL exposes filesystems to Linux applications in WSL2. While WSL1 translated Linux syscalls into equivalent Windows ones in a kernel driver, WSL2 runs a full-fledged Linux kernel in a lightweight VM. Filesystems on the host are exposed to this Linux instance via a connection to a 9P2000.L fileserver over a Hyper-V Socket. (That's the remote filesystem protocol developed as part of the Plan 9 OS.) 9P2000 models a lightweight interface layer much more closely related to Dokan or FUSE than protocols like SMB/CIFS or NFS. FWIW, the Plan 9 server used by Windows was not developed specifically for WSL2, but was instead added as part of Windows Server Containers.

After extensive disassembly and debugging, it was discovered that the server code resides in vp9fs.dll, and is hosted in a dllhost.exe process which runs with the token of the user that launched the WSL distro. This DLL directly invokes ZwQueryDirectoryFile with the FileIdExtdDirectoryInformation information class, which is not supported by Dokan. A fallback mechanism exists to try more-common information classes, but it is only triggered by NTSTATUS values of STATUS_INVALID_INFO_CLASS, STATUS_INVALID_PARAMETER, and STATUS_NOT_SUPPORTED, not STATUS_NOT_IMPLEMENTED -- which is the one Dokan returns. (Indeed, patching the DLL to overwrite STATUS_NOT_IMPLEMENTED values with STATUS_INVALID_PARAMETER fixes the issue.)

As far as standards go, [MS-FSCC] sections 2.4 and 2.5 seem to indicate that STATUS_INVALID_PARAMETER is the correct return code for functions which are implemented but which are asked to query or set an unimplemented information class.

[mrnerdhair]

If anyone needs a fix right now and doesn't care how quick and dirty it is, I've cooked up a patch with Cheat Engine that will make WSL 2 compatible with current versions of Dokan.

Don't use this unless you understand what it does.