chore: development v0.2.137 - comprehensive testing complete [auto-commit]

Author: githubrobbi

CHANGELOG.md

@@ -23,7 +23,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Cleaned up all TTAPI references from justfile and build scripts
 - Updated justfile header and recipes for UFFS
 
-## [0.2.136] - 2026-01-27
+## [0.2.137] - 2026-01-27
 
 ### Added
 - Baseline CI validation for modernization effort
@@ -46,7 +46,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 ### Fixed
 - Various MFT parsing edge cases
 
-[Unreleased]: https://github.com/githubrobbi/UltraFastFileSearch/compare/v0.2.136...HEAD
-[0.2.136]: https://github.com/githubrobbi/UltraFastFileSearch/compare/v0.2.114...v0.2.136
+[Unreleased]: https://github.com/githubrobbi/UltraFastFileSearch/compare/v0.2.137...HEAD
+[0.2.137]: https://github.com/githubrobbi/UltraFastFileSearch/compare/v0.2.114...v0.2.137
 [0.2.114]: https://github.com/githubrobbi/UltraFastFileSearch/releases/tag/v0.2.114
 

Cargo.lock

@@ -39,7 +39,7 @@ exclude = [
 # Workspace Package Metadata (inherited by all crates)
 # ─────────────────────────────────────────────────────────────────────────────
 [workspace.package]
-version = "0.2.136"
+version = "0.2.137"
 edition = "2024"
 rust-version = "1.85"
 license = "MPL-2.0 OR LicenseRef-UFFS-Commercial"

Cargo.toml

@@ -126,17 +126,50 @@ This fails because:
 3. `block_on` tries to block the current thread to run the future
 4. But the blocking thread is still part of the tokio runtime, causing the panic
 
-### Fix Applied
-Changed all occurrences to use `block_in_place` which properly handles this case:
+### First Fix Attempt (v0.2.135) - FAILED
+Changed all occurrences to use `block_in_place`:
 ```rust
 tokio::task::block_in_place(|| {
     tokio::runtime::Handle::current().block_on(async { ... })
 })
 ```
 
-`block_in_place` temporarily moves the current thread out of the async worker pool,
-allowing `block_on` to work correctly.
+This still failed because `Handle::block_on` panics when called from within an async context,
+even when using `block_in_place`. The issue is that `block_in_place` only moves the current
+thread out of the async worker pool temporarily, but `block_on` still detects it's within
+a runtime context.
+
+### Second Fix (v0.2.136) - SUCCESS
+The correct solution is to use `spawn_blocking` with **synchronous** function versions:
+
+1. **Added sync function variants:**
+   - `open_sync(drive)` - synchronous version of `open`
+   - `read_all_sync()` - synchronous version of `read_all`
+   - `read_with_progress_sync(callback)` - synchronous version of `read_with_progress`
+   - `read_all_index_sync()` - synchronous version of `read_all_index`
+   - `read_index_with_progress_sync(callback)` - synchronous version of `read_index_with_progress`
+
+2. **Fixed async wrapper functions to use spawn_blocking with sync versions:**
+   - `read_single_drive` - uses `spawn_blocking` + `open_sync` + `read_all_sync`/`read_with_progress_sync`
+   - `read_single_drive_index` - uses `spawn_blocking` + `open_sync` + `read_all_index_sync`/`read_index_with_progress_sync`
+   - `read_and_cache_single_drive` - uses `spawn_blocking` + `read_and_cache_single_drive_sync`
+   - `apply_usn_updates_to_cached_index` - uses `spawn_blocking` + `apply_usn_updates_to_cached_index_sync`
+
+### Why This Works
+- `spawn_blocking` moves the closure to a dedicated blocking thread pool
+- The sync functions run entirely on that blocking thread without any async/await
+- No `block_on` is called, so no runtime nesting occurs
+- Parallel drive reading is preserved via `JoinSet::spawn` - each drive gets its own blocking thread
 
 ### Files Modified
-- `crates/uffs-mft/src/reader.rs`: Fixed 5 occurrences of the pattern
+- `crates/uffs-mft/src/reader.rs`:
+  - Added 5 sync function variants
+  - Added 2 sync helper functions (`read_and_cache_single_drive_sync`, `apply_usn_updates_to_cached_index_sync`)
+  - Fixed 4 async wrapper functions to use `spawn_blocking` with sync versions
+
+### CI Result
+- **Status**: ✅ PASSED
+- **Version**: 0.2.136
+- **Total Time**: 485s
+- **Commit**: `cdafbae2e` pushed to `main`
 

LOG/2026_01_28_10_00_CHANGELOG_HEALING.md

@@ -21,7 +21,7 @@ Traditional file search tools (including `os.walk`, `FindFirstFile`, etc.) work
 
 **UFFS reads the MFT directly** - once - and queries it in memory using Polars DataFrames. This is like reading the entire phonebook once instead of looking up each name individually.
 
-### Benchmark Results (v0.2.136)
+### Benchmark Results (v0.2.137)
 
 | Drive Type | Records | Time | Throughput |
 |------------|---------|------|------------|
@@ -33,7 +33,7 @@ Traditional file search tools (including `os.walk`, `FindFirstFile`, etc.) work
 
 | Comparison | Records | Time | Notes |
 |------------|---------|------|-------|
-| **UFFS v0.2.136** | **18.7 Million** | **~142 seconds** | All disks, fast mode |
+| **UFFS v0.2.137** | **18.7 Million** | **~142 seconds** | All disks, fast mode |
 | UFFS v0.1.30 | 18.7 Million | ~315 seconds | Baseline |
 | Everything | 19 Million | 178 seconds | All disks |
 | WizFile | 6.5 Million | 299 seconds | Single HDD |