Error: Cannot read file – File > Open – UI freeze on large datasets

The short answer

File > Open in Blender is a synchronous, main-thread operation. Reading the file, decompressing it, running versioning, relinking pointers, and rebuilding the dependency graph all finish before the window manager's event loop runs again. The window stops repainting, the OS may label it "Not Responding," and no progress bar or cancel button appears — not because loading failed, but because the .blend reader does not feed the job/progress system that rendering and baking use. Error: Cannot read file is a separate code path, reported only when the file is missing, unreadable, or structurally invalid. A long silent load is expected behavior, not an error state.

Confirmed behavior vs. likely explanation

Confirmed for Blender 2.8x–3.x as far as my knowledge goes — verify on your exact build, since I cannot confirm what changed after 3.5:

• File > Open blocks the UI, with no progress indicator or cancel for the load itself.
• The error string appears for unreadable or corrupt files, not for slow ones.
• Blender separately warns when a file was written by a newer release — a distinct message that is easy to mistake for the corrupt-file error.

Likely but unconfirmed: for most heavy scenes, the bulk of wall-clock time is spent after the disk read — in library relinking, versioning, and depsgraph rebuild. That is why faster storage alone often yields less speedup than expected.

Blocking vs. asynchronous loading

Aspect	Blocking (current)	Asynchronous
State complexity	One scene database, no locks, undo code assumes exclusive access	Locking or double-buffered scenes; old and new coexist
Peak memory	One file's worth	Higher while both scenes exist
Cancellation	None	Required, with defined semantics
User experience	Unresponsive window, no feedback	Responsive UI, spinner possible

Blocking keeps memory and state simple and avoids partial loads. Async loading buys responsiveness and cancellation at the cost of a thread-safe handoff, higher peak memory, and a larger crash surface in versioning and undo code — which is why blocking has historically been the simpler, safer default.

Should there be a progress bar, and can errors be unified?

A true percentage is unrealistic: total work is not known before parsing completes. What is feasible with the existing status-bar job mechanism is an indeterminate spinner plus cancel, with missing, corrupt, and newer-version outcomes routed through the same report channel for consistent feedback. Whether anything like this landed after 3.5 I cannot confirm — the "up to 3.5" claim in the discussion is user-reported, so check the release notes for your version before assuming.

What to do about a 200 MB+ file today

1. Launch from a terminal so hidden reports and warnings are visible:

   blender --debug

   then open the file, or pass the path on the command line.
2. Untick Load UI in the Open dialog to skip the screen layout stored in the file — a small, free win.
3. Purge orphaned data-blocks before saving (File > Clean Up in recent releases) so dead data stops costing load time.
4. Split heavy assets into linked libraries so the main file stays small.
5. Keep the file on a fast local disk, off network shares, and excluded from real-time antivirus scanning. If the file is saved compressed, weigh smaller I/O against the extra decompression CPU.
6. Watch memory: a 200 MB .blend can expand to several GB in RAM once data-blocks are unpacked and linked. If the machine swaps during load, the fix is RAM or a smaller scene — not a progress bar.

One detail that changes the recommendation

During the freeze, check Task Manager (Windows) or Activity Monitor (macOS):

• Roughly one core pegged at 100% CPU means the time is in relinking, versioning, or depsgraph work — fix by restructuring or splitting the file.
• Low CPU with high disk latency means the load is I/O-bound — fix the storage path, network share, or antivirus exclusion.

Which of those you observe decides whether the next step is file restructuring or storage work. That single observation is the missing detail; share it and the recommendation follows directly.