Feature request: Would like a way to toggle on more information

[schneems]

Today

fs_err::copy(&tar_dir, &path).map_err(Error::IoError)?;

Produces this error:

❌ failed to copy file from <path1> to <path2>

Proposal

I would like the ability to tell fs_err to give me more information on failure. In this case the directory for file did not exist and I had to:

fs_err::create_dir_all(path.parent().expect("Parent dir")).map_err(Error::IoError)?;
fs_err::copy(&tar_dir, &path).map_err(Error::IoError)?;

I'm not sure on the mechanics, but I would like to add debugging info like:

❌ failed to copy file from <path1> to <path/to/path2> (no such directory </path/to/>)

Or

❌ failed to copy file from <path/to/path1> to <path2> (directory <path/to> exists but is empty)

Or

❌ failed to copy file from <path1> to path2> (<path1> is a directory, not a file)

I did something like this for missing commands on the PATH https://github.com/schneems/which_problem, but it seems there are more states to consider here.

Consequences

The debugging process will possibly generate N additional filesystem calls. I think that the costs would be worth it (compute time is cheaper than developer time and a good user experience is the goal). Maybe people who use this library prefer better diagnostic errors every time? I feel someone will likely not want it or want to disable it. We could feature flag it.

[andrewhickman]

Thanks for the suggestion! This does sound like it would be useful

I think this would add more complexity to this crate than I'm keen to support, however. Needing custom logic for many different API calls and status codes sounds like a lot of extra maintenance.

That which-problem tool looks super useful btw!

[schneems]

I've been poking at this on-and-off for awhile. I'm not quite ready to send a PR, but to give you an idea of what I'm envisioning is possibly hooking into something like this https://github.com/schneems/path_facts with a feature to optionally enhance the output.

The thought here was to extract the logic into its own encapsulated module and provide a small public API, then fs-err wouldn't have to do much other than add an enhancement path. Posting here to let you know that I'm still interested in this. Also possibly to get some high level feedback or temperature reading on the idea. Ranging from steaming-hot (love it) to ice cold (never in a million years) or somewhere inbetween. I'm not looking for a binding opinion, more of a "am I on the right track" or not.

[andrewhickman]

I like the idea of having a dependency on another crate which provides more debug information, gated behind a feature flag. I can imagine this being super useful to enable crate-wide while debugging, but disabling in production. I'd be open to a PR adding a dependency on path_facts

[schneems]

Sorry for the PR spam. I got https://github.com/andrewhickman/fs-err/pull/81 ready which doesn't affect MSRV. Let me know your thoughts when you get time.