Closed jyn514 closed 4 years ago
Strangely the documentation for WalkDir
says that this shouldn't be an error:
Follow symbolic links. By default, this is disabled. When yes is true, symbolic links are followed as if they were normal directories and files. If a symbolic link is broken or is involved in a loop, an error is yielded.
https://docs.rs/walkdir/2.2.9/walkdir/struct.WalkDir.html#method.follow_links
This might be a bug in WalkDir, not Rustwide.
My guess is that, since WalkDir
is not configured to follow symlinks, copy_dir
tries to call std::fs::copy
on the broken symlink:
I think the best fix is to instead configure WalkDir
to follow them, so we don't have to deal with the issue ourselves.
If WalkDir followed links, we would still get the same error, just a little sooner:
If a symbolic link is broken or is involved in a loop, an error is yielded.
Maybe we could configure std::fs::copy
not to follow symbolic links? I don't see a way to do that in the documentation though ... https://doc.rust-lang.org/std/fs/fn.copy.html
WalkDir
has an API to check whether or not it's a symbolic link at least, maybe we could do something like this:
for entry in WalkDir::new(&src).into_iter()
.filter_entry(|entry| !(entry.path_is_symlink() && /* check that entry isn't a broken link */) {
// ...
}
I'd consider a link being broken an error though.
I feel like that should be up to the developer ... But in any case we should give a better error message if we're going to leave this in place, 'No such file or directory' sounds very strange for a copy.
Yeah, adding context to the errors mentioning the file name would probably solve it.
I had a link in the top level directory that was broken, took me forever to figure out what the error actually was.
The error is coming from somewhere near here: https://github.com/rust-lang/rustwide/blob/master/src/crates/local.rs#L51