Hi there! I'm filing this based on some triage I did of astral-sh/uv#18793 in astral-sh/uv#18815. I'm not 100% sure if it's a bug or not, but it's arguably surprising in terms of how it diverges from fs::read_link on POSIX-y hosts.
Expected behavior
I expected junction::get_target to return the PathBuf of a junction's target, even if that underlying target doesn't exist (e.g. was deleted). This would be similar to how fs::read_link behaves -- calling read_link on a broken symbolic link reads the link's metadata, without actually validating it.
Actual behavior
Instead of returning the (unvalidated) destination, junction::get_target pre-validates that the target actually exists. It does this with Path::exists, which follows the junction:
|
pub fn get_target(junction: &Path) -> io::Result<PathBuf> { |
|
// MSRV(1.63): use Path::try_exists instead |
|
if !junction.exists() { |
|
return Err(io::Error::new(io::ErrorKind::NotFound, "`junction` does not exist")); |
|
} |
Proposed fix
Whether or not this needs a fix depends on whether it's intended behavior or not -- I could see an argument either way 🙂. If it's intended behavior, I propose updating the public documentation for junction::get_target to explain that it actually validates the target, which makes it different from fs::read_link. If it's unintended behavior, I propose removing that Path::exists check and reading only the junction's metadata, so that the API behaves similarly to fs::read_link.
Please let me know if you'd prefer either of these! I'm happy to send a PR for either, if desired.
Hi there! I'm filing this based on some triage I did of astral-sh/uv#18793 in astral-sh/uv#18815. I'm not 100% sure if it's a bug or not, but it's arguably surprising in terms of how it diverges from
fs::read_linkon POSIX-y hosts.Expected behavior
I expected
junction::get_targetto return thePathBufof a junction's target, even if that underlying target doesn't exist (e.g. was deleted). This would be similar to howfs::read_linkbehaves -- callingread_linkon a broken symbolic link reads the link's metadata, without actually validating it.Actual behavior
Instead of returning the (unvalidated) destination,
junction::get_targetpre-validates that the target actually exists. It does this withPath::exists, which follows the junction:junction/src/internals.rs
Lines 131 to 135 in 7ce8dc2
Proposed fix
Whether or not this needs a fix depends on whether it's intended behavior or not -- I could see an argument either way 🙂. If it's intended behavior, I propose updating the public documentation for
junction::get_targetto explain that it actually validates the target, which makes it different fromfs::read_link. If it's unintended behavior, I propose removing thatPath::existscheck and reading only the junction's metadata, so that the API behaves similarly tofs::read_link.Please let me know if you'd prefer either of these! I'm happy to send a PR for either, if desired.