edit 2.0.0 / 1.2.1 fails to open files on WinFsp-FUSE mounted drives (e.g. SFTP mounts): ERROR_UNRECOGNIZED_VOLUME (os error 1005)

Environment

• edit versions tested, both fail:
  • 2.0.0 (portable from GitHub releases)
  • 1.2.1 (C:\Windows\System32\edit.exe)
• OS: Windows 11, build 10.0.26200
• The drive is an SFTP server mounted as a drive letter via WinFsp 2.1.25156 + cgofuse 1.6.0 (custom Go app using cgofuse's nocgo WinFsp backend). Same failure is expected on other WinFsp-FUSE mounts (rclone mount / SSHFS-Win) — not verified yet.

Steps to reproduce

1. Mount any WinFsp-FUSE drive on a drive letter (Z: in my case).
2. In PowerShell: cd Z:\some\folder
3. Run edit index.html (the file exists; reading/writing it via notepad.exe, PowerShell and Explorer all work).

Actual result (edit 2.0.0)

The volume does not contain a recognized file system.
Please make sure that all required file system drivers are loaded and that the volume is not corrupted. (os error 1005)

Exit code 1, no UI shown. 1.2.1 shows the same error in the older Error 0x800703ed: ... format. It also fails from a local CWD with an absolute path (edit Z:\some\folder\index.html), so the CWD is not the trigger.

Expected result

Edit opens the file. Other editors (notepad.exe) open and save the same file fine.

Analysis

The file open itself succeeds — a WinFsp request trace shows Create/Read/Close all succeed. The error comes from file-identity detection in sys::file_id():

1. GetFileInformationByHandleEx(FileIdInfo) fails on WinFsp-FUSE volumes ("The parameter is incorrect").
2. The fallback std::fs::canonicalize() (→ GetFinalPathNameByHandleW) then fails with ERROR_UNRECOGNIZED_VOLUME (os error 1005).
3. In documents.rs the error is propagated with ? (Some(sys::file_id(...)?)), so Edit aborts instead of opening the file.

Probe results against a handle to the file on the mounted drive:

OK    CreateFile                                    handle ok
OK    GetFileInformationByHandle                    size=11
FAIL  GetFileInformationByHandleEx(FileIdInfo)      The parameter is incorrect.
FAIL  GetFinalPathNameByHandleW                     ERROR_UNRECOGNIZED_VOLUME (os error 1005)
OK    GetVolumeInformationW (drive root)            label ok, FileSystemName = "FUSE"
OK    GetVolumeInformationByHandleW                 ok

Plain reads/writes/renames through the drive work, and notepad.exe works on the same file.

Suggested improvement

When both FileIdInfo and canonicalize fail, consider degrading gracefully instead of failing the open — e.g. fall back to FileId::Path(path) with the plain (non-canonicalized) path, so files can still be opened on file systems that don't support these queries. (The GetFinalPathNameByHandleW failure itself is likely a WinFsp FUSE-layer limitation, but a graceful fallback in Edit would make it robust everywhere.)

Workaround

Use notepad / VS Code for files on FUSE-mounted drives.

This report was generated by AI.

Start in documents.rs at the file-identity handling that propagates sys::file_id(), then inspect sys::file_id() and reproduce the failure on a WinFsp-FUSE-mounted drive. Verify that a file whose FileIdInfo and canonicalize queries fail can still be opened, while preserving normal identity handling for supported volumes.