Module trash_worker 

Every call into the trash crate runs on one dedicated thread.

The crate documents undefined behaviour when it is called from more than one thread at a time on Linux/FreeBSD, and on Windows it initializes COM per calling thread. A single long-lived worker satisfies both: calls are serialized, and COM is set up once (spec §7.3).

Spec: docs/specs/SPEC_FILE_BROWSER_PANE_2026_10_01.md §7.3, §9.1.5.

Statics

WORKER 🔒

The worker’s queue. None if the thread could not be started, in which case every trash call fails cleanly instead of panicking a handler.

Functions

context 🔒

A TrashContext that, on macOS, uses NSFileManager rather than the crate’s default of scripting Finder: the Finder route raises an Automation prompt (“AgentMux wants to control Finder”), and once refused, later deletes silently do nothing (spec §9.1.5).

describe 🔒

A readable clause for a trash::Error, whose own Display is its Debug dump.

path_key 🔒

A path’s identity for matching a trashed item’s original location: the display form, case-folded on Windows, whose filesystems are case-insensitive and whose Recycle Bin reports plain (non-verbatim) paths.

restore_paths

Put each of targets back from the Trash: for each, the most recently trashed item whose original location is that path. Must be called on the trash thread (via run). One result per target, in order.

run

Run f on the trash thread and wait for its answer without blocking the async runtime.

trash_path

Move path to the Trash. Must be called on the trash thread (via run). The crate trashes a link itself, not its target.

worker 🔒

Type Aliases

Job 🔒