sxyazi/yazi · error · io::Error

InvalidData

InvalidData

Error message

trash item has no put-back location

What it means

To restore a macOS trashed item, DsStore needs the put-back location (ptbL field) recorded in .DS_Store. When the DsStore entry for the item has parent = None — no ptbL record was found for that item name — join cannot reconstruct the original path and returns this InvalidData error.

Source

Thrown at yazi-fs/src/trash/macos/ds_store.rs:42

			let location = locations.entry_ref(OsStr::new(&record.name)).or_default();
			match &record.field.fourcc().bytes() {
				b"ptbL" => location.parent = Some(value.into()),
				b"ptbN" => location.name = Some(value.into()),
				_ => {}
			}
		}

		Ok(locations)
	}

	pub(super) fn join(&self, rel: &Path) -> io::Result<PathBuf> {
		if !rel.is_relative() || rel.has_parent_component() {
			return Err(io::Error::new(io::ErrorKind::InvalidInput, "invalid trash entry path"));
		}

		let parent = self.parent.as_deref().ok_or_else(|| {
			io::Error::new(io::ErrorKind::InvalidData, "trash item has no put-back location")
		})?;

		let name = self.name.as_deref().ok_or_else(|| {
			io::Error::new(io::ErrorKind::InvalidData, "trash item has no put-back name")
		})?;

		let mut components = Path::new(name).components();
		if !matches!(components.next(), Some(Component::Normal(_))) || components.next().is_some() {
			return Err(io::Error::new(io::ErrorKind::InvalidData, "invalid trash put-back name"));
		}

		let top_path = Path::new("/").join(parent).join(name);
		Ok(if rel.as_os_str().is_empty() { top_path } else { top_path.join(rel) })
	}
}

View on GitHub (pinned to 8ebf930f17)

Solutions

  1. Fall back to a manual restore: move the item from ~/.Trash to the desired location yourself since macOS metadata is missing.
  2. Open the item in Finder and use "Put Back" so Finder reconstructs/uses its own metadata, then retry.
  3. Check that the trash's .DS_Store still contains ptbL records for the item (parse it with a .DS_Store inspector).
  4. If .DS_Store was deleted or regenerated, put-back data is unrecoverable — restore manually.

Example fix

// before: assuming put-back data always exists
let dest = ds_store.join(rel)?;
// after: degrade gracefully when put-back metadata is absent
let dest = match ds_store.join(rel) {
    Ok(dest) => dest,
    Err(_) => trash_dir.join(rel), // fallback: restore in place
};
Defensive patterns

Strategy: fallback

Validate before calling

fn has_put_back_metadata(store: &DsStore, name: &std::ffi::OsStr) -> bool {
    // parent (ptbL) must be present for restore to be possible
    store.can_restore(name) // expose a predicate or check the parsed ptbL record
}

Try / catch

let dest = match ds_store.join(&rel) {
    Ok(dest) => dest,
    Err(e) if e.to_string().contains("no put-back location") => {
        eprintln!("no Finder put-back data; restoring to trash-relative path");
        trash_dir.join(&rel)
    }
    Err(e) => return Err(e.into()),
};

Prevention

When it happens

Trigger: Restoring an item whose name has no ptbL record in the trash's .DS_Store — e.g. the .DS_Store lacks put-back data for that item, only ptbN was recorded, the record value was empty (skipped during parse), or a freshly created/truncated .DS_Store.

Common situations: Items dragged to trash by tools that don't write put-back metadata; Finder's .DS_Store regenerated or deleted, losing ptbL/ptbN records; third-party trash utilities bypassing Finder metadata; very new trashed items whose metadata wasn't flushed.

Related errors


AI-assisted analysis of sxyazi/yazi@8ebf930f17 (2026-09-02). Data as JSON: /api/errors/c7baf0ab904fb3dc. Report an issue: GitHub.