Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

report and skip broken symlinks #136

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

adnelson
Copy link

I was running rewatch build on my project for the first time and it failed, confusingly claiming Could not read folder: src..., despite src clearly existing.

Upon some investigation the error was actually that I had a broken symlink (pointing to a non-existent file) in my project directory tree, which caused the like let metadata = fs::metadata(&entry_path_buf)?; to return an error, tanking the whole process.

The fix I have here checks specifically for a broken symlink, and if found, reports it and skips (continues) the loop. With this change, my project compiled without errors.

I also added the text of the error to the println!s reporting errors in a few places, with the idea that that might help make things clearer to a user. It's not part of the core fix here, so feel free to remove if undesirable.

Comment on lines +157 to +160
if is_broken_symlink(&entry_path_buf) {
println!("Warning: '{}' is a broken symlink", entry_path_buf.display());
continue;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just an idea, but could this check be moved to if an actual error is produced? I assume it'd be in the line below, let metadata = fs::metadata(&entry_path_buf)?;.

Maybe it doesn't matter in practice, but sometimes these FS APIs incur latency, so it'd be nice to avoid using it unless actually needed, which I guess is only if it actually errors.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah - +1 @adnelson -- I think push these to both 169, as well as 471. I think both those could potentially be symlinked folders. Other than that, great stuff.

It reminds me that I should probably pick up the PR to add proper log levels again at some point.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adnelson -- We've added some better loggin structure, feel free to rebase and update the PR.

If you don't feel like it - I'd be happy to take this over and finish it, I think this could be nice to have :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants