mirrors/arti.git/crates/tor-dirmgr/src/err.rs, branch arti-v1.2.5

tor-persist: Provide FsMistrustErrorExt, and use it

2023-12-13T17:02:45Z

This code needs fs_mistrust::Error and tor_error::ErrorKind. I think we probably don't want fs_mistrust to depend on tor_error or vice versa. tor_persist is approximately the place where these two threads of thought come together, and it's currently the lowest place where this is needed. Use it in tor-dirmgr too, which is currently the other place that embodies this knowledge about fs_mistrust::Error.

tor-dirmgr: impl AsRef for Error

2022-11-04T19:01:24Z

This allows use with tor_error::Report.

`TaskSchedule`: give error on `sleep*()` if last handle is dropped

2022-09-07T13:22:38Z

This fixes an busy-loop. When the last `TaskHandle` on a `TaskSchedule` is dropped, the schedule is permanently canceled: whatever operation it was scheduling should no longer be performed. But our code was broken: the `sleep()` and `sleep_until_wallclock()` functions don't verify whether the handles are dropped or not. This breakage caused an CPU-eating busy-loop in `sleep_until_wallclock`. With this patch, we now return a `Result<(), SleepError>` from these functions. Fixes #572.

Use anonymize_home() when displaying various messages.

2022-08-31T13:38:35Z

Closes #555

dirmgr: Add a helper to create LockFile errors.

2022-07-18T14:10:28Z

dirmgr: Make UnrecognizedSchema more helpful

2022-07-14T13:53:17Z

dirmgr: Clarify disk IO errors.

2022-07-14T13:27:29Z

dirmgr: style edits to error messages.

2022-07-14T12:40:42Z

Do not include error source() in display() format.

2022-06-21T18:14:14Z

According to doc/Errors.md, and in keeping with current best practices, we should not include display an error's `source()` as part of that error's display method. Instead, we should let the caller decide to call source() and display that error in turn. Part of #323.

DirMgr:: Remove Error::NoChange as redundant.

2022-05-25T12:58:37Z

Now that the relevant functions now report changed/not-changed status via a boolean out-parameter (see !527), there's no reason to have a separate NoChanged error case. Closes #484.