fix: handle invalid working directories gracefully with --full-path

[Xavrir]

Fixes #1900

When using --full-path, fd panics if the current working directory becomes invalid (e.g., deleted or inaccessible) during execution. This occurs because the code attempts to resolve relative paths after the cwd is no longer accessible.

This fix replaces the panic with a graceful error message, allowing fd to exit cleanly instead of crashing.

Changes:

• Modified path resolution logic to handle invalid cwd gracefully
• Added regression test to prevent future panics in this scenario
• Verified with cargo test and cargo clippy locally

[tmccombs]

This is a decent attempt, although there are some minor issues.

however, I'm not sure this is the best approach. One thing I notice is that we are calling current_dir() every time we construct an absolute path.

I wonder if maybe it would be better to re-architect this so that we only call current_dir() once, at the beginning, and if that succeeds, then we can create absolute paths from that infallibly afterwords, and if it fails we can fail early, without needing to check for every entry. And it would probably be more performant as well.

It would mean that if the current directory disappears while fd is running you will continue to get results that may no longer be valid, which may be good or bad depending on the situation.

[Xavrir]

You're right, caching cwd once at startup is the better approach. I reworked the PR: Config now gets a cwd: Option<PathBuf> populated when --full-path is set, and search_str_for_entry uses it infallibly via a new make_absolute(path, cwd) function. If the cwd can't be retrieved, fd fails early before the walk begins. This let me drop FatalError entirely, revert the batch() Vec allocation, and delete the test that was mutating process-global state.

[tavianator]

I know you cut and pasted this code so no need to fix this in this PR, but we already have a better approach here:

fd/src/dir_entry.rs

Lines 132 to 146 in 7027d45

	fn file_name(&self) -> OsString {
	let name = match &self.inner {
	DirEntryInner::Normal(e) => e.file_name(),
	DirEntryInner::BrokenSymlink(path) => {
	// Path::file_name() only works if the last component is Normal,
	// but we want it for all component types, so we open code it.
	// Copied from LsColors::style_for_path_with_metadata().
	path.components()
	.next_back()
	.map(|c| c.as_os_str())
	.unwrap_or_else(|| path.as_os_str())
	}
	};
	name.to_owned()
	}

I think we should expose DirEntry::file_name() and then just use that rather than doing this.

[Xavrir]

Noted, will keep in mind for a follow-up.

[tmccombs]

Suggested change

	pub fn make_absolute(path: &Path, cwd: &Path) -> PathBuf {
	if path.is_absolute() {
	return path.to_path_buf();
	}
	let path = path.strip_prefix(".").unwrap_or(path);
	cwd.join(path)
	}
	pub fn make_absolute<'a, 'b>(path: &'a Path, cwd: &'b Path) -> Cow<'a, Path> {
	if path.is_absolute() {
	return Cow::Borrowed(path);
	}
	let path = path.strip_prefix(".").unwrap_or(path);
	Cow::Owned(cwd.join(path))
	}

[tmccombs]

nit: it seems slightly more intuitive to me for the cwd to come first, but that might just be me.

[tmccombs]

nit: perhaps full_path_base would be more indicative of how this is used?

[tmccombs]

I know this is the same as what we had before, and doesn't need to be changed in this PR, but this could actually be a Borrowed, if the original path was absolute.

It would be a little simpler if we changed the new make_absolute function to return a Cow<'a, OsStr> directly instead of a PathBuf or Cow