Commit e772737
remove: add retries to client directory removal
Summary:
While debugging `sl worktree add` failures, one failure came across as a failed eden removal -> corrupt eden state -> failed worktree add. The user seemed to have ran `eden doctor` which got them to a better state, but I'd like to try to address the root issue.
Their eden removal failed with (https://fburl.com/scuba/edenfs_cli_usage/ogclkwez) :
```
Failed to remove client config directory for {removal_target}: Directory not empty (os error 39)
```
as per: https://doc.rust-lang.org/std/fs/fn.remove_dir_all.html#errors
> This function may return `io::ErrorKind::DirectoryNotEmpty` if the directory is concurrently written into, which typically indicates some contents were removed but not all. `io::ErrorKind::NotFound` is only returned if no removal occurs.
On the host I investigated, there was only a `local` directory there, which was half removed. So there must have been some outstanding overlay writes happening while the repo was being removed: P2265496617
This diff migrates to a retrying removal (used already in this file elsewhere), which gives us a better chance of a removal if there are racing writes.
As a followup too, we probably want to treat this as non-fatal and continue removal. I suspect we will see more instances of removals happening with other processes using the repo, so these best effort retries might not be enough. I think its fair to honor the removal over the potential usage of a repo.
Reviewed By: janezhang10
Differential Revision: D99915460
fbshipit-source-id: b27b20725a7335ae0ec3eb50721e2395612bc0a71 parent 639a39d commit e772737
1 file changed
+2
-1
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
25 | 25 | | |
26 | 26 | | |
27 | 27 | | |
| 28 | + | |
28 | 29 | | |
29 | | - | |
| 30 | + | |
30 | 31 | | |
31 | 32 | | |
32 | 33 | | |
| |||
0 commit comments