Fix: Keep folder metadata reads from blocking the UI

[nietus]

Resolved / Related Issues

• Related to Bug: Files stops responding while loading network share content #14777. This addresses the synchronous folder-metadata read that can still block the UI after enumeration. The issue was marked available by an org member.

Folder enumeration queues desktop.ini loading on the UI dispatcher, where File.Exists and File.ReadLines can block while an SMB share stops responding. Read the file on a worker instead, then apply the metadata and background image on the dispatcher. A cancelled navigation or changed working directory discards the result so it cannot overwrite the new folder's metadata.

The existing task still completes before adaptive layout uses DesktopIni. Windows networking timeouts are still controlled by the OS; this change keeps that particular read off the UI thread.

Steps used to test these changes

Tested the Debug/x64 build of this branch against main (9bc7472) on Windows 11 (26200), using a real SMB share that I made slow on purpose.

1. Ran a Samba 4.20 server in a local container and connected to it as \127.0.0.1\share (net use /TCPPORT:4450). Oplocks and leases were disabled on the server so the SMB client could not answer the read from its cache. The folder has 25 files and a desktop.ini with a [FilesApp] Files_BackgroundImage entry.
2. Started Files on the Home page, added 1 s of latency to every packet from the server (tc netem delay 1000ms), then opened the folder with files-dev.exe "\127.0.0.1\share\pasta-lenta".
3. While the folder loaded, a script sent WM_NULL to the main window every 25 ms (SendMessageTimeout, 100 ms timeout) and logged every stretch where the UI thread did not answer. Five runs per build, fresh process each time.

Build	Longest UI hang	Total time unresponsive
main	11.1–12.2 s	17.3–19.2 s
this PR	4.1–4.3 s	8.2–9.0 s

The 11–12 s hang that follows enumeration on main is gone with this change. Two hangs remain: one of about 4.2 s that is identical in both builds, and a shorter one (1–3.6 s) after it. I have not tracked down where those come from, so this PR does not make a slow share fully smooth.

4. Checked that the folder background from desktop.ini is still applied, both on the slow share and on a local folder.

Not tested: a share that stops answering completely (only a slow one).

[CLAassistant]

All committers have signed the CLA.

[Josh65-2201]

Thanks for the contribution, please actually check your changes and not copy and paste what the AI thinks the test is

[nietus]

Fair point, sorry about that. I've now run the app itself against a slow SMB share, main vs this branch, and replaced the test section with what I measured. In that setup it removes the longest hang (11–12 s) but not all of them; details are in the description.