sxyazi/yazi · warning · anyhow::Error

Failed to retrieve file info

Error message

Failed to retrieve file info

What it means

After engine::rename succeeds for a pair, bulk rename stats the new path with engine::file(new) to build the File handed to FilesOp::rename. If that stat fails the pair is recorded as failed with "Failed to retrieve file info" — although the rename already happened on disk. The in-memory listing is simply not updated for that pair.

Source

Thrown at yazi-actor/src/mgr/bulk_rename.rs:132

		let permit = WATCHER.acquire().await.unwrap();
		let (mut failed, mut succeeded) = (Vec::new(), HashMap::with_capacity(todo.len()));
		for (o, n) in todo {
			let (Ok(old), Ok(new)) =
				(Self::replace_url(&selected[o.0], root, &o), Self::replace_url(&selected[n.0], root, &n))
			else {
				failed.push((o, n, anyhow!("Invalid new or old file name")));
				continue;
			};

			if maybe_exists(&new).await && !engine::must_identical(&old, &new).await {
				failed.push((o, n, anyhow!("Destination already exists")));
			} else if let Err(e) = engine::rename(&old, &new).await {
				failed.push((o, n, e.into()));
			} else if let Ok(f) = engine::file(new).await {
				succeeded.insert(old, f);
			} else {
				failed.push((o, n, anyhow!("Failed to retrieve file info")));
			}
		}

		if !succeeded.is_empty() {
			let it = succeeded.iter().map(|(o, n)| (o.as_url(), n.url.as_url()));
			log_if_err!(Pubsub::pub_after_bulk_rename(it));
			FilesOp::rename(succeeded);
		}
		drop(permit);

		if !failed.is_empty() {
			Self::output_failed(failed).await?;
		}
		Ok(())
	}

	fn opener() -> Option<OpenerRuleArc> {
		YAZI

View on GitHub (pinned to 94abcfa92f)

Solutions

1. Verify on disk — the rename most likely already applied; refresh the directory listing
2. Retry the stat once after a short delay on remote/archive backends
3. Suspend sync clients and watchers during large bulk renames

// Rename already succeeded; retry only the stat before declaring failure.
} else if let Ok(f) = engine::file(&new).await {
    succeeded.insert(old, f);
} else if let Ok(f) = tokio::time::sleep(std::time::Duration::from_millis(200)).await,
    engine::file(&new).await
{
    succeeded.insert(old, f);
} else {
    failed.push((o, n, anyhow!("Failed to retrieve file info")));
}

When it happens

Trigger: Rename succeeds but the follow-up metadata read fails: remote/archive backends with lagging metadata, the renamed file being moved/deleted immediately after by a watcher or concurrent process, or permission changes on the destination directory.

Common situations: Bulk renaming on network mounts or inside archives; running while file watchers/sync clients react to each rename and touch the files again.

Related errors

• Failed to retrieve file info
• Invalid new or old file name
• Invalid path
• Destination already exists
• trash item has no put-back location

AI-assisted analysis of sxyazi/yazi@94abcfa92f (2026-08-16). Data as JSON: /api/errors/63b5f9d62e2fa0ae. Report an issue: GitHub.