`std::fs::canonicalize` failed to process path mounted with cppcryptfs/dokan under windows

[9-2-1]

I tried this code:

use std::fs::canonicalize;

pub fn main() {
    println!("{}", canonicalize("F:\\gofs").unwrap().display());
    // Where F:\gofs is a path mounted with cppcryptfs which use Dokan library.
}

I expected to see this happen:
print \\?\F:\gofs.

Instead, this happened:

thread 'main' panicked at src/main.rs:5:45:
called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "系统找不到指定的文件。" }

I have double checked that F:\gofs is exist and accessible.

Meta

rustc --version --verbose:

rustc 1.80.1 (3f5fd8dd4 2024-08-06)
binary: rustc
commit-hash: 3f5fd8dd41153bc5fdca9427e9e05be2c767ba23
commit-date: 2024-08-06
host: x86_64-pc-windows-msvc
release: 1.80.1
LLVM version: 18.1.7

Backtrace

stack backtrace:
   0: std::panicking::begin_panic_handler
             at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library\std\src\panicking.rs:652
   1: core::panicking::panic_fmt
             at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library\core\src\panicking.rs:72
   2: core::result::unwrap_failed
             at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library\core\src\result.rs:1679
   3: enum2$<core::result::Result<std::path::PathBuf,std::io::error::Error> >::unwrap
             at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23\library\core\src\result.rs:1102
   4: test_dunce::main
             at .\src\main.rs:5
   5: core::ops::function::FnOnce::call_once<void (*)(),tuple$<> >
             at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23\library\core\src\ops\function.rs:250
   6: core::hint::black_box
             at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23\library\core\src\hint.rs:338

[ChrisDenton]

Does it work if you use "F:\\gofs\\"? (note the extra \\ at the end).

[Fulgen301]

GetFinalPathNameByHandleW documents:

Some third-party drivers can create a drive letter or mount point without using the Mount Manager. If the Mount Manager was not used to create the drive, then VOLUME_NAME_DOS or VOLUME_NAME_GUID will not succeed; only VOLUME_NAME_NT will be available. To determine the drive letter for the volume device path, use the QueryDosDevice function on every drive letter until a matching device name is found.

This may be the case here.