[Better file sizes in Explorer details] Proposal: move folder-size calculation off Explorer's synchronous size-query path

[insane66613]

Mod author: @m417z

Proposal

Consider moving folder-size acquisition off Explorer's synchronous CFSFolder::_GetSize property-query path and returning cached results asynchronously.

The goal is to make Explorer's property lookup non-blocking even when Everything IPC or filesystem enumeration is slow, unavailable, or temporarily unhealthy.

Explorer asks for folder size
        |
        v
    cache lookup
      /    \
    hit    miss
     |       |
 return    queue background calculation
 cached      |
 value       v
        Everything / filesystem
              |
              v
            cache
              |
              v
        notify Explorer to refresh

This is intended as a design discussion first, not a request to merge an existing fork wholesale.

Motivation

There have been reports where folder-size calculation correlates with Explorer stalls or degraded responsiveness:

• [Better File Sizes in Explorer Details] Explorer hangs when everything service not presented #4275 — Explorer hanging when Everything wasn't available. The report became non-reproducible, so the root cause wasn't established.
• [Better file sizes in Explorer details] Lags when accessing mapped network drives #4417 — lag while browsing mapped network drives with the mod enabled.

I also submitted m417z/my-windhawk-mods#84 for a narrower, independent issue: bounding Everything IPC waits and fixing receiver initialization failure paths that can otherwise wait indefinitely. That PR deliberately does not change the synchronous folder-size architecture.

Even with bounded IPC, doing size acquisition directly from Explorer's property-query path means any permitted wait or fallback filesystem work still contributes directly to Explorer latency. An async/cache design would isolate that work from the UI/property request.

Existing proof of concept

I have a local enhanced fork that uses a background queue, cache, and refresh notification and has been usable in Explorer. That implementation also contains unrelated changes and some behavior that should not be upstreamed as-is, so I would reimplement this against current upstream rather than submit the fork wholesale.

If this direction is useful, I can prepare a focused PR that preserves current upstream behavior, including reparse/junction and OneDrive handling, network-drive safeguards, current PIDL/path semantics, Tiles/Content/Details pane/Status Bar integration, locale-aware size formatting, and Everything-specific compatibility behavior.

Questions for maintainers

1. Would an asynchronous cache/worker model be acceptable for folder-size calculation?
2. Is SHChangeNotify (or another shell notification mechanism) the preferred way to invalidate/refresh the displayed Size value when a background result arrives?
3. Would you prefer the async behavior for all folder-size modes, or only the Everything-backed mode initially?

If the design is acceptable, I'll prepare the implementation as a separate focused PR based directly on current upstream.

[m417z]

Thanks for the suggestion and the implementation offer, but I'm not sure it's worth the complication. With the rather fast Everything v3 API query (0.3777 ms per query) I think it's good enough to run the query synchronously. The v2 API is slower but it will be phased away with time. Manual calculation is low priority given how much better Everything integration is.

• Explorer hanging when Everything wasn't available. The report became non-reproducible, so the root cause wasn't established.

The reporter had various issues and crashes, so it's unclear what was going on there, whether the problem is related to the mod, and if the timeout would help in this case.

• lag while browsing mapped network drives with the mod enabled.

That was addressed by not resolving reparse points on network drives.