Reid Rankin

I'm experiencing the same behavior, and the UI appears to indicate that a StableBit Cloud account is now mandatory. I *will not* set up an account just to *use my own computer*. Compromise of such an account could lead to remote deactivation of a core part of my machine's storage system and is unacceptable.

@Nights0ng The fixes referenced here look like they've made it into the 2.2.5.1237 RC version that's available from the official download page. (The betas are available here.) WSL2 support works pretty OK with these fixes; you can list directories and execute files just like you'd expect. Performance isn't stellar, but not that bad either. My primary workflow is VS Code with a Remote-WSL connection, and my primary dev directory is on a DrivePool drive, and it works fine. Stuff involving access to lots and lots of tiny files, like some git checkouts and npm installs, can be somewhat slower than they would be on a native drive, but IMHO it's a price worth paying for the redundancy. (IDK whose fault the performance issues are; could be DrivePool's fault, but it could just as easily be inherent to Windows' 9P2000 server implementation. And I'm using SMR drives, which suck in their own special way. But it's good enough as-is, and I'm happy.)

Here's the DrivePool tracking issue; it appears has been resolved in version 2.3.0.1193.

For future reference, here's the Dokan issue and PR. Several similar issues were already filed with the WSL repo, so I've added comments to link back to the Dokan issue and hopefully help people get things sorted. I've also cooked up a Cheat Engine script that will patch vp9fs.dll at runtime to properly handle both Dokan's STATUS_NOT_IMPLEMENTED and DrivePool's STATUS_INTERNAL_ERROR, if you need a fix right now and don't mind using what's essentially a video game trainer to make it happen. Don't use this unless you understand what it does. fixDrivePoolWSL.CT

After WAY TOO MUCH DEBUGGING I've discovered that there's a built-in mechanism in vp9fs.dll to downgrade the FileInformationClass it requests. It tries the following in order: FileIdExtdDirectoryInformation (60) FileIdFullDirectoryInformation (38) FileIdBothDirectoryInformation (37) FileFullDirectoryInformation (2) FileDirectoryInformation (1) The trick is that it only searches through this list if it gets one of the following NTSTATUS error codes: STATUS_INVALID_INFO_CLASS (0xC0000003) STATUS_INVALID_PARAMETER (0xC000000D) STATUS_NOT_SUPPORTED (0xC00000BB) Note that this does not include the STATUS_INTERNAL_ERROR (0xC00000E5) code which is returned by CoveFs in response to the unsupported request made with FileIdExtdDirectoryInformation. I've also realized that Dokan filesystems have the same problem; in their case they return STATUS_NOT_IMPLEMENTED (0xC0000002), which while close does not earn it a cigar. (It does, however, result in a more intelligible "Function not implemented" error on the Linux side instead of a generic "Input/output error".) The other good news is that I hacked up a patch in Cheat Engine (yeah, it's been a long day) that forces vp9fs.dll to pretend the error code is always 0xC0000003 and it makes all of the above work fine. I was worried that there would be more incompatibilities even once the directory listings got working because I saw some other error codes popping up -- but they're caused by the Windows ACLs in my specific environment and are working exactly like they should. So I suggest DrivePool change its error code returned in these cases to one of these 3 more-specific, magical codes -- personally, I like the STATUS_INVALID_INFO_CLASS. Tomorrow I'll work up a PR for the Dokan people, and I'll also file an issue with the WSL issue tracking repo to try to get them to include a few more error codes in their magical "stuff that works" list.

I've been following up on this with some disassembly and debugging to try and figure out what precisely is going wrong. WSL2's "drvfs" is just a 9P2000.L file server implementation (yep, that's the protocol from Plan 9) exposed over a Hyper-V Socket. (On the Windows side, this is known as a VirtIO socket; on the Linux side, however, that means something different and they're called AF_VSOCK.) The 9P server itself is hard to find because it's not in WSL-specific code -- it's baked into the Hyper-V "VSMB" infrastructure for running Linux containers, which predates WSL entirely. The actual server code is in vp9fs.dll, which is loaded by both the WSL2 VM's vmwp.exe instance and a copy of dllhost.exe which it starts with the token of the user who started the WSL2 distro. Because the actual file system operations occur in the dllhost.exe instance they can use the proper security token instead of doing everything as SYSTEM. The relevant ETW GUID is e13c8d52-b153-571f-78c5-1d4098af2a1e. This took way too long to find out, but allows you to build debugging logs of what the 9P server is doing by using the tracelog utility. tracelog -start p9trace -guid "#e13c8d52-b153-571f-78c5-1d4098af2a1e" -f R:\p9trace.etl <do the stuff> tracelog -stop p9trace The directory listing failure is reported with a "Reply_Rlerror" message with an error code of 5. Unfortunately, the server has conveniently translated the Windows-side NTSTATUS error code into a Linux-style error.h code, turning anything it doesn't recognize into a catch-all "I/O error" in the process. Luckily, debugging reveals that the underlying error in this case is an NTSTATUS of 0xC00000E5 (STATUS_INTERNAL_ERROR) returned by a call to ZwQueryDirectoryFile. This ZwQueryDirectoryFile call requests the new-to-Win10 FileInformationClass of FileIdExtdDirectoryInformation (60), which is supposed to return a structure with an extra ReparsePointTag field -- which will be zero in almost all cases because most things aren't reparse points. Changing the FileInformationClass parameter to the older FileIdFullDirectoryInformation (38) prevents the error, though it results in several letters being chopped off of the front of each filename because the 9P server expects the larger struct and has the wrong offsets baked in. So things would probably work much better if CoveFs supported that newfangled FileIdExtdDirectoryInformation option and the associated FILE_ID_EXTD_DIR_INFO struct; it looks like that should be fairly simple. That's not to say that other WSL2-specific issues aren't also present, but being able to list directories would give us a fighting chance to work around other issues on the Linux side of things.

Just want to add my two cents as a loyal DrivePool user -- WSL2 support is important to me. I'd like to do my dev work in DrivePool so it's duplicated.