[PR #5049] [MERGED] fix(desktop): verbatim path handling in disk resolution #5031

New issue

Closed

opened 2026-03-17 02:31:06 +03:00 by kerem · 0 comments

kerem commented

2026-03-17 02:31:06 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/hoppscotch/hoppscotch/pull/5049
Author: @CuriousCorrelation
Created: 5/3/2025
Status: ✅ Merged
Merged: 5/21/2025
Merged by: @AndrewBastin

Base: next ← Head: feat-better-verbatim-path-handling

📝 Commits (1)

d383aab fix(storage): verbatim path handling in disk resolution

📊 Changes

6 files changed (+114 additions, -28 deletions)

View changed files

📝 packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-appload/Cargo.lock (+1 -0)
📝 packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-appload/Cargo.toml (+1 -0)
📝 packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-appload/src/storage/manager.rs (+13 -4)
📝 packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-appload/src/ui/windows/posit.rs (+2 -2)
📝 packages/hoppscotch-desktop/src-tauri/Cargo.lock (+92 -17)
📝 pnpm-lock.yaml (+5 -5)

📄 Description

The storage init was failing on Windows when checking available disk space due to verbatim paths (also known as extended-length paths) returned by std::fs::canonicalize().

Windows has two path formats: traditional paths limited to 260 characters, and extended-length paths (prefixed with \\?\) that support longer paths.

While Rust's std::path is "platform-independent", Windows-specific behavior still requires special consideration for these extended-length paths.

This fixes that.

Closes HFE-839
Closes #4859

Basically the issue occurred because std::fs::canonicalize() on Windows may return extended-length paths when:

The path exceeds 260 characters
The path contains certain special characters
The system is configured to use extended paths (fairly common on Win 10/11)

The root issue is when comparing the canonicalized storage path against disk mount points.

A verbatim path like \\?\C:\Users\SomeUser\AppData\... would fail to match against the disk's mount point C:\ because the comparison was done as a path string prefix check. This isn't handled by std::path, see dunce's README

This caused the disk resolution to fail with "Disk not found" errors, preventing the app from initializing the bundle, which would show a 404.

See the docs at (https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-file-namespaces).

dunce crate provides cross-platform path canonicalization that specifically handles Windows verbatim paths correctly. When given a verbatim path, dunce safely strips the \\?\ prefix when possible while maintaining path validity:

let normalized_path = dunce::canonicalize(&storage_path).unwrap_or(storage_path.clone());

The normalization preserves the verbatim prefix only when necessary - for example with reserved filenames like \\?\C:\COM1 or paths containing certain special characters.

On non-Windows systems, dunce behaves identically to std::fs::canonicalize().

Testing:

Traditional Windows paths (< 260 chars)
Extended-length paths (> 260 chars) that get verbatim prefixes
Paths containing special characters
UNC paths and network shares
All supported non-Windows platforms

Notes to reviewers

To test this, launch the app on Windows, have the install location be ~95% full (using something like fsutil file createnew largefile.bin <size-in-bytes>), launch the app, you should see 404 because the app bundle wasn't loaded due to 1. incorrect space calculation or 2. disk mismatch. Now try the same thing with this patch.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/hoppscotch/hoppscotch/pull/5049 **Author:** [@CuriousCorrelation](https://github.com/CuriousCorrelation) **Created:** 5/3/2025 **Status:** ✅ Merged **Merged:** 5/21/2025 **Merged by:** [@AndrewBastin](https://github.com/AndrewBastin) **Base:** `next` ← **Head:** `feat-better-verbatim-path-handling` --- ### 📝 Commits (1) - [`d383aab`](https://github.com/hoppscotch/hoppscotch/commit/d383aab88a188358f38e8bbe8ca4e7aeb660b7d0) fix(storage): verbatim path handling in disk resolution ### 📊 Changes **6 files changed** (+114 additions, -28 deletions) <details> <summary>View changed files</summary> 📝 `packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-appload/Cargo.lock` (+1 -0) 📝 `packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-appload/Cargo.toml` (+1 -0) 📝 `packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-appload/src/storage/manager.rs` (+13 -4) 📝 `packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-appload/src/ui/windows/posit.rs` (+2 -2) 📝 `packages/hoppscotch-desktop/src-tauri/Cargo.lock` (+92 -17) 📝 `pnpm-lock.yaml` (+5 -5) </details> ### 📄 Description The storage init was failing on Windows when checking available disk space due to verbatim paths (also known as extended-length paths) returned by `std::fs::canonicalize()`. Windows has two path formats: traditional paths limited to 260 characters, and extended-length paths (prefixed with `\\?\`) that support longer paths. While Rust's `std::path` is "platform-independent", Windows-specific behavior still requires special consideration for these extended-length paths. This fixes that. Closes HFE-839 Closes #4859 Basically the issue occurred because `std::fs::canonicalize()` on Windows may return extended-length paths when: 1. The path exceeds 260 characters 2. The path contains certain special characters 3. The system is configured to use extended paths (fairly common on Win 10/11) The root issue is when comparing the canonicalized storage path against disk mount points. A verbatim path like `\\?\C:\Users\SomeUser\AppData\...` would fail to match against the disk's mount point `C:\` because the comparison was done as a path string prefix check. This isn't handled by `std::path`, see [dunce's README](https://gitlab.com/kornelski/dunce/-/blob/master/README.md?ref_type=heads&plain=1#L16-17) This caused the disk resolution to fail with "Disk not found" errors, preventing the app from initializing the bundle, which would show a `404`. See the docs at (https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-file-namespaces). `dunce` crate provides cross-platform path canonicalization that specifically handles Windows verbatim paths correctly. When given a verbatim path, dunce safely strips the `\\?\` prefix when possible while maintaining path validity: ```rust let normalized_path = dunce::canonicalize(&storage_path).unwrap_or(storage_path.clone()); ``` The normalization preserves the verbatim prefix only when necessary - for example with reserved filenames like `\\?\C:\COM1` or paths containing certain special characters. On non-Windows systems, dunce **behaves identically** to `std::fs::canonicalize()`. Testing: - Traditional Windows paths (< 260 chars) - Extended-length paths (> 260 chars) that get verbatim prefixes - Paths containing special characters - UNC paths and network shares - All supported non-Windows platforms ### Notes to reviewers To test this, launch the app on Windows, have the install location be ~95% full (using something like `fsutil file createnew largefile.bin <size-in-bytes>`), launch the app, you should see `404` because the app bundle wasn't loaded due to 1. incorrect space calculation or 2. disk mismatch. Now try the same thing with this patch. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>