[PR #5226] [MERGED] fix(desktop): disk space detection on overlay fs #5113

New issue

Closed

opened 2026-03-17 02:35:27 +03:00 by kerem · 0 comments

kerem commented

2026-03-17 02:35:27 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/hoppscotch/hoppscotch/pull/5226
Author: @CuriousCorrelation
Created: 7/7/2025
Status: ✅ Merged
Merged: 7/11/2025
Merged by: @jamesgeorge007

Base: patch ← Head: fix-desktop-disk-space-detection-on-overlayfs

📝 Commits (2)

a0e0f36 fix(desktop): disk space detection on overlay fs
be49257 fix(desktop): canonicalize storage path once

📊 Changes

9 files changed (+37 additions, -31 deletions)

View changed files

📝 packages/hoppscotch-common/package.json (+1 -1)
📝 packages/hoppscotch-desktop/package.json (+1 -1)
📝 packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-appload/LICENSE.md (+1 -1)
📝 packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-appload/README.md (+1 -1)
📝 packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-appload/src/lib.rs (+1 -1)
📝 packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-appload/src/storage/manager.rs (+23 -17)
📝 packages/hoppscotch-desktop/src-tauri/Cargo.lock (+1 -1)
📝 packages/hoppscotch-desktop/src-tauri/Cargo.toml (+1 -1)
📝 pnpm-lock.yaml (+7 -7)

📄 Description

This fixes the storage manager incorrectly reporting 0 bytes available space on systems with overlay filesystems like composefs, which was causing "Insufficient disk space" errors even when adequate storage exists.

Closes FE-911
Closes #5182

The issue occurred because the disk matching logic used starts_with to find mount points containing the storage path, which would match the root filesystem (/) before finding the actual underlying filesystem with available space. On systems with overlay filesystems, the root mount point shows 0 available space even if the actual storage location has plenty of space.

What's changed

This updates the disk matching logic in the ensure_space method to find the most specific (longest) mount point that contains the storage path rather than the first match. The fix filters disks where the storage path starts with the mount point and selects the disk with the longest matching mount point path.

For example, on the affected system the storage path (see the listed issue) /home/user/.config/app would previously match the composefs root / (0 bytes available) instead of the underlying filesystem /var/home (748G available).

Notes to reviewers

This change preserves existing functionality for standard filesystem layouts and handles edge cases where canonicalization fails.

Testing should verify that disk space detection works correctly on both standard fs and systems with overlay fs like composefs, mainly on UBlue Fedora Bazzite (where the original issue was reported), should also work with NixOS.

The fix should now correctly identify the underlying filesystem with actual available space instead of overlay filesystems with 0 capacity.

_{🔄 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/5226 **Author:** [@CuriousCorrelation](https://github.com/CuriousCorrelation) **Created:** 7/7/2025 **Status:** ✅ Merged **Merged:** 7/11/2025 **Merged by:** [@jamesgeorge007](https://github.com/jamesgeorge007) **Base:** `patch` ← **Head:** `fix-desktop-disk-space-detection-on-overlayfs` --- ### 📝 Commits (2) - [`a0e0f36`](https://github.com/hoppscotch/hoppscotch/commit/a0e0f369c7118c371c4769867a76c836a3f63f8c) fix(desktop): disk space detection on overlay fs - [`be49257`](https://github.com/hoppscotch/hoppscotch/commit/be4925715f00a9737f2d8c9a35a81ae253717144) fix(desktop): canonicalize storage path once ### 📊 Changes **9 files changed** (+37 additions, -31 deletions) <details> <summary>View changed files</summary> 📝 `packages/hoppscotch-common/package.json` (+1 -1) 📝 `packages/hoppscotch-desktop/package.json` (+1 -1) 📝 `packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-appload/LICENSE.md` (+1 -1) 📝 `packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-appload/README.md` (+1 -1) 📝 `packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-appload/src/lib.rs` (+1 -1) 📝 `packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-appload/src/storage/manager.rs` (+23 -17) 📝 `packages/hoppscotch-desktop/src-tauri/Cargo.lock` (+1 -1) 📝 `packages/hoppscotch-desktop/src-tauri/Cargo.toml` (+1 -1) 📝 `pnpm-lock.yaml` (+7 -7) </details> ### 📄 Description This fixes the storage manager incorrectly reporting 0 bytes available space on systems with overlay filesystems like `composefs`, which was causing "Insufficient disk space" errors even when adequate storage exists. Closes FE-911 Closes #5182 The issue occurred because the disk matching logic used `starts_with` to find mount points containing the storage path, which would match the root filesystem (`/`) before finding the actual underlying filesystem with available space. On systems with overlay filesystems, the root mount point shows `0` available space even if the actual storage location has plenty of space. ### What's changed This updates the disk matching logic in the `ensure_space` method to find the most specific (longest) mount point that contains the storage path rather than the first match. The fix filters disks where the storage path starts with the mount point and selects the disk with the longest matching mount point path. For example, on the affected system the storage path (see the listed issue) `/home/user/.config/app` would previously match the `composefs` root `/` (0 bytes available) instead of the underlying filesystem `/var/home` (748G available). ### Notes to reviewers This change preserves existing functionality for standard filesystem layouts and handles edge cases where canonicalization fails. Testing should verify that disk space detection works correctly on both standard fs and systems with overlay fs like composefs, mainly on UBlue Fedora Bazzite (where the original issue was reported), should also work with NixOS. The fix should now correctly identify the underlying filesystem with actual available space instead of overlay filesystems with 0 capacity. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>