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
- Mount any WinFsp-FUSE drive on a drive letter (
Z: in my case).
- In PowerShell:
cd Z:\some\folder
- 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():
GetFileInformationByHandleEx(FileIdInfo) fails on WinFsp-FUSE volumes ("The parameter is incorrect").- The fallback
std::fs::canonicalize() (→ GetFinalPathNameByHandleW) then fails with ERROR_UNRECOGNIZED_VOLUME (os error 1005).
- 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.
Environment
C:\Windows\System32\edit.exe)Steps to reproduce
Z:in my case).cd Z:\some\folderedit index.html(the file exists; reading/writing it via notepad.exe, PowerShell and Explorer all work).Actual result (edit 2.0.0)
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():GetFileInformationByHandleEx(FileIdInfo)fails on WinFsp-FUSE volumes ("The parameter is incorrect").std::fs::canonicalize()(→GetFinalPathNameByHandleW) then fails withERROR_UNRECOGNIZED_VOLUME(os error 1005).documents.rsthe 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:
Plain reads/writes/renames through the drive work, and notepad.exe works on the same file.
Suggested improvement
When both
FileIdInfoandcanonicalizefail, consider degrading gracefully instead of failing the open — e.g. fall back toFileId::Path(path)with the plain (non-canonicalized) path, so files can still be opened on file systems that don't support these queries. (TheGetFinalPathNameByHandleWfailure 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.