fix: eliminate desktop stall when deleting large files

Deleting a big file froze the desktop for seconds: ext2 FreeBlock did 4 synchronous disk I/Os per data block (bitmap + BGDT read/write), and the file manager deleted single files inline on the desktop main thread. - Ext2: batch block frees per block group; keep the bitmap resident, clear bits in memory, flush bitmap + BGDT once per group transition. Also covers the truncate-on-overwrite path. - Ext2: refuse to mount volumes with block size > 4096; temp buffers throughout the driver are single 4 KiB pages, so larger blocks would overflow them (our mkfs always uses 4K). - Files: route single-file deletes past 4 MiB to the background worker + progress dialog; refuse (instead of stalling inline) when another file operation already owns the worker. Co-Authored-By: Claude Fable 5 <[email protected]>
2026-07-09 23:20:19 +02:00
parent 349816a63a
commit e1a5364824
4 changed files with 133 additions and 13 deletions
@@ -54,6 +54,12 @@ struct FileManagerVirtualEntry {
 // misbehaving driver and bounds memory. Far above any realistic directory.
 inline constexpr int FM_ENTRY_HARD_CAP = 8192;

+// Single-file deletes at or below this size are freed inline; larger files go
+// to the background worker + progress dialog. Freeing a big file rewrites the
+// filesystem allocation bitmaps and can take seconds on real disks, which would
+// otherwise stall the desktop (Files runs inside desktop.elf).
+inline constexpr uint64_t FILEMANAGER_DELETE_INLINE_MAX_BYTES = 4ull * 1024 * 1024;
+
 struct FileManagerState {
    char current_path[256];
    FileManagerLocation history[16];