[Bug]: Deep Cleanup hangs on macOS temporary FIFOs and cancellation never completes

[ivg-design]

MangoDisk version

1.0.5

Operating system and version

macOS 26.6 (25G72), Apple Silicon

Problem description

Deep Cleanup can hang indefinitely while processing Old temporary files (system.user-temp). The UI remains responsive, but cancellation stays on Stopping cleanup... forever. Quitting or force-quitting the app is the only recovery.

This reproduced in two consecutive app sessions:

• In the first session, cleanup stopped producing progress for about 32 minutes. A cancel request was logged, but neither cleanup_finished nor operation_finished was emitted before the app was restarted.
• In the second session, cleanup stopped on Old temporary files again. The cancel request was accepted, but the operation lock remained held and no cleanup history record was finalized.

Steps to reproduce

1. On macOS, have one or more FIFO/named-pipe entries under the process temporary directory ($TMPDIR). Developer tools can leave these naturally; the affected machine had old diagnostic/tool pipes in this directory.
2. Run Deep Cleanup with Old temporary files selected.
3. Cleanup reaches that rule and remains on Processing indefinitely.
4. Press Cancel.

Expected behavior

• Non-regular filesystem entries such as FIFOs and sockets are skipped or rejected without blocking.
• Cancellation completes within a bounded time.
• The operation lock is released and a truthful result/history entry is finalized.

Actual behavior

• The cleanup worker blocks in a kernel open() call.
• The main thread and UI remain responsive.
• Cancellation is recorded but cannot be observed by the blocked worker.
• The operation lock remains held and history is not finalized.

Process-sample evidence

Two independent process samples taken several minutes apart placed the cleanup worker in the same stack for every sample:

CleanupService::execute_deep_cleanup_step_with_progress
  -> execute_rule
  -> delete_entry
  -> prepare_path_for_permanent_delete
  -> std::fs::File::open
  -> open
  -> __open

The worker also retained a directory handle on $TMPDIR. The directory contained multiple FIFOs with no open writer endpoints. A read-only blocking open of a FIFO waits for a writer indefinitely.

Likely root cause

On Unix, prepare_path_for_permanent_delete() calls fs::File::open(path) before checking that the captured metadata represents a regular file or directory:

https://github.com/harry0703/MangoDisk/blob/main/src-tauri/crates/mangodisk-core/src/filesystem/permanent_delete.rs#L117-L177

delete_entry() checks cancellation immediately before calling that function, but the flag cannot be checked again while open() is blocked:

https://github.com/harry0703/MangoDisk/blob/main/src-tauri/crates/mangodisk-core/src/cleanup/rule_execution.rs#L470-L490

The macOS temporary-files rule traverses ${temp}:

https://github.com/harry0703/MangoDisk/blob/main/src-tauri/crates/mangodisk-core/rules/filesystem/macos/system/system.user-temp.toml#L13-L25

Because the matcher runs after prepare_path_for_permanent_delete(), even a FIFO that would later fail the seven-day matcher can trigger the blocking open.

Suggested repair

1. Use symlink_metadata to reject unsupported special-file types before opening the identity handle.
2. On Unix, open with nonblocking and no-follow semantics (O_NONBLOCK | O_NOFOLLOW) while preserving the existing handle/path identity and TOCTOU checks.
3. Add a regression test containing a FIFO in a cleanup root and assert the call returns promptly without mutation.
4. Add a cancellation-latency test for special files in system.user-temp.

[harry0703]

Thanks for the detailed report and process samples — they made the root cause very clear. You were right: on Unix, MangoDisk opened the FIFO in blocking mode before checking its file type, which left the cleanup worker stuck in open() and unable to observe cancellation.

This has now been fixed:

• FIFOs, Unix sockets, and other special files are identified and skipped before deletion
• Unix identity handles now use non-blocking, no-follow open flags
• The existing path and physical identity checks remain in place
• Regression tests now cover real FIFOs, Unix sockets, and cancellation responsiveness
• The full test suite passes on both macOS and Windows

The fix has been merged into main and will be included in the next release. Thanks again for the excellent report and investigation.

[ivg-design]

Sure thing!

Are you planning to add an embedded MCP for agent assisted cleanup?

[harry0703]

Thanks for the suggestion! I like the idea of agent-assisted cleanup.

After thinking about it, embedding an MCP server may add more complexity than we need right now. MangoDisk already has a CLI with structured JSON output, and it uses the same Core safety checks as the desktop app. Letting an agent call the CLI for scanning, dry runs, and cleanup may be a simpler and more appropriate approach.

The flow I have in mind is: the agent runs a read-only scan, explains the recommendations, asks the user for approval, and only then runs the CLI cleanup command.

Do you see any important use case or benefit that MCP would provide over direct CLI integration? I would be interested to hear what workflow you had in mind or any other ideas you may have.

[ivg-design]

I've developed some tools of my own - with built in MCP - my thoughts on the matter are that for the agent to be effective in assisting it needs to have a way to visibly drive the interface - so that the user can follow along - and make corrections - and see formatted and organized output outside of a CLI... that being said it may be possible to use the CLI to do that - so that CLI and the GUI can share the same session - rather than being separate, and then expose some way for the CLI to interact with GUI session...

The important requirement for me isn’t MCP by itself; it’s a shared, visible session between the agent and the desktop app. The agent should be able to start a scan or prepare a cleanup plan, have that exact session appear in the GUI, let the user inspect and revise the selections, and then execute only after explicit approval. Progress and cancellation should remain visible in the app.
A CLI-first design could support this if the desktop app exposed a local session bridge and the CLI could create or attach to session IDs. MCP could then be an optional typed adapter over that same API rather than a separate cleanup implementation.