sxyazi/yazi · warning · anyhow::Error

Failed to retrieve file info

Error message

Failed to retrieve file info

What it means

After engine::create_dir_all / engine::create_new reports success for an entry, bulk_create stats the new path with engine::file(dist) to build the File handed to FilesOp::create. If that stat fails, the entry is recorded as failed with "Failed to retrieve file info" even though the create itself succeeded — the file may well exist on disk.

Source

Thrown at yazi-actor/src/mgr/bulk_create.rs:92

				failed.push((entry, anyhow!("Invalid path")));
				continue;
			};

			let result: io::Result<()> = if entry.is_dir {
				engine::create_dir_all(&dist).await
			} else if let Some(parent) = dist.parent() {
				engine::create_dir_all(parent).await.ok();
				engine::create_new(&dist).await.map(|_| ())
			} else {
				Err(io::Error::other("No parent directory"))
			};

			if let Err(e) = result {
				failed.push((entry, e.into()));
			} else if let Ok(f) = engine::file(dist).await {
				succeeded.push(f);
			} else {
				failed.push((entry, anyhow!("Failed to retrieve file info")));
			}
		}

		if !succeeded.is_empty() {
			// log_if_err!(Pubsub::pub_after_bulk_create(it));  // FIXME
			FilesOp::create(succeeded);
		}
		drop(_permit);

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

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

View on GitHub (pinned to 94abcfa92f)

Solutions

1. Verify on disk first — the file usually exists; refresh the directory listing
2. Retry the stat once after a short delay (engine::file again) before treating the entry as failed
3. Pause or exclude sync clients/watchers from the target tree during bulk runs

// Treat 'Failed to retrieve file info' as a soft failure: the create likely succeeded.
if let Ok(_) = result {
    let f = match engine::file(&dist).await {
        Ok(f) => f,
        Err(_) => tokio::time::sleep(std::time::Duration::from_millis(200)).await,
            engine::file(&dist).await.with_context(|| format!("stat after create: {}", dist))?,
    };
    succeeded.push(f);
}

When it happens

Trigger: Create succeeds but the immediately following metadata read fails: eventually-consistent remote/archive backends, the new file being deleted between create and stat by a watcher or concurrent process, or permission loss on the parent directory after creation.

Common situations: Bulk creation over network mounts, ssh/smb/archive VFS with metadata lag; large batches while sync clients (Dropbox, rsync jobs) touch the same tree; sandboxed environments restricting stat.

Related errors

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

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