sxyazi/yazi · warning · io::Error

trash item has no put-back location

Error message

trash item has no put-back location

What it means

Thrown by DsStore::join on macOS when the ~/.Trash/.DS_Store record for a trashed item has no ptbL ('put-back location') field, so the original parent directory is unknown. Finder writes ptbL/ptbN when it moves an item to the Trash; anything that bypasses Finder leaves the record incomplete. Inside yazi the error is caught with .ok() during list()/entry(), so it degrades the entry to original == None instead of propagating.

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 94abcfa92f)

Solutions

1. Do not rely on put-back for this item: restore it manually by moving it out of ~/.Trash, or use Trash:rename to place it at the desired path.
2. If Finder put-back is required, move the item back out and re-trash it from Finder so .DS_Store gets fresh ptbL/ptbN records.
3. In code, check entry.original (Lua) / entry.original (Rust field) for None before calling restore, and skip or prompt for a destination.
4. Inspect ~/.Trash/.DS_Store (e.g. `xattr`/hex dump or ds_parser) to confirm the ptbL field is missing for the affected name.

Example fix

-- Lua: before
ya.fs("trash"):restore(entries)
-- after: only restore entries that carry put-back info
local trash = ya.fs("trash")
local restorable = {}
for _, e in ipairs(entries) do
  if e.original ~= nil then table.insert(restorable, e) end
end
if #restorable > 0 then trash:restore(restorable) end

-- Lua: before restoring, require put-back info on every entry
local function has_put_back(e) return e.original ~= nil end
local restorable = vim.tbl_filter(has_put_back, entries) -- or a plain loop

-- Lua
local function is_restorable(e)
  return type(e) == "table" and e.original ~= nil
end

local ok, err = trash:restore(entries)
if not ok and tostring(err):find("put-back", 1, true) then
  -- offer manual move out of ~/.Trash instead of retrying
end

When it happens

Trigger: DsStore::parse finds a record for the file name in ~/.Trash/.DS_Store, but only non-ptbL fields (or nothing) exist for it; ds.join(rel) is then called during Trash::list (root listing) or Trash::entry, hitting self.parent == None.

Common situations: User moved a file into ~/.Trash with `mv` from a shell or script; a third-party 'trash' CLI that does not write .DS_Store; .DS_Store was reset by a disk-cleanup tool; item was trashed from a non-root volume where Finder stores put-back info elsewhere.

Related errors

• trash item has no put-back name
• invalid trash put-back name
• trash item has no put-back location
• invalid trash entry path
• trash item has no put-back location

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