Trashing a symlink to a folder trashes the target folder, not the symlink

[niieani]

Reproduction steps

1. create a symlink to a folder somewhere outside of your workdir
2. right click from files -> Trash
3. the whole target directory gets trashed, and the symlink remains where it was

I haven't tested with Delete, but it's likely this behavior would be the same, resulting in potential data loss!

Current vs. Expected behavior

• only the symlink gets trashed

Zed version and system specs

Zed 0.233.10
Commit: 350f338
Version: 0.233.10+stable.250.350f33871e84d5ed83a403523e9490b9bf014a94
OS: macOS 26.4 (25E246)

Attach Zed log file

Zed.log

2026-04-25T16:35:11-07:00 ERROR [worktree] error reading file "/Volumes/Projects/Software/vendor/repos" on event: canonicalizing "/Volumes/Projects/Software/vendor/repos": No such file or directory (os error 2)

Relevant Zed settings

No response

Relevant Keymap

No response

(for AI issues) Model provider details

No response

If you are using WSL on Windows, what flavor of Linux are you using?

None

[m13v]

the canonicalize line in your error log is the giveaway. hit this exact thing shipping a macos swift app, FileManager.trashItem preserves symlinks fine but anything upstream calling realpath() or URL.resolvingSymlinksInPath() has already destroyed the symlink identity by the time the trash op runs. rust equivalent is std::fs::canonicalize() vs std::fs::read_link(). worth tracing the worktree path handling to find where the link gets resolved before the file op, the bug is almost always in the layer above the trash call.

[yeskunall]

Hey @niieani -- thanks for surfacing this. Looks like this bug was introduced by #53311, which added self.canonicalize(path) to the unified RealFs::trash impl. Before that PR, macOS’s trash path passed the path through unmodified (first via a custom NSWorkspace.recycleURLs impl, then briefly via the trash crate after #52012’s unification) -- both preserve symlink identity.

The post-#53311 canonicalize resolves the symlink before handing off to trash::delete_with_info, so the target gets recycled instead.

zed/crates/fs/src/fs.rs

Lines 926 to 946 in 6242777

	async fn trash(&self, path: &Path, _options: RemoveOptions) -> Result<TrashedEntry> {
	// We must make the path absolute or trash will make a weird abomination
	// of the zed working directory (not usually the worktree) and whatever
	// the path variable holds.
	let path = self
	.canonicalize(path)
	.await
	.context("Could not canonicalize the path of the file")?;
	let (tx, rx) = futures::channel::oneshot::channel();
	std::thread::Builder::new()
	.name("trash file or dir".to_string())
	.spawn(|| tx.send(trash::delete_with_info(path)))
	.expect("The os can spawn threads");
	Ok(rx
	.await
	.context("Tx dropped or fs.restore panicked")?
	.context("Could not trash file or dir")?
	.into())
	}

The comment above tells me the intent was absolutization, not symlink resolution; std::path::absolute would do that without following symlinks.

Previous artefact(s):

• Linux Trashing a symlink to a directory will trash the target directory not the symlink #22399 (on Linux tho)