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

Missing structs #29

Open
Emerentius opened this issue Sep 19, 2020 · 2 comments
Open

Missing structs #29

Emerentius opened this issue Sep 19, 2020 · 2 comments
Labels
enhancement New feature or request

Comments

@Emerentius
Copy link
Contributor

There exist several structs in std::fs which don't appear in fs_err

  • DirBuilder
  • Metadata
  • FileType
  • Permissions

Of these, the first 2 have methods returning io::Result<_> which would benefit from wrappers.
The last 2 don't have any fallible methods. If fs-err re-exported them, it would add to the "drop-in" quality of the crate. The downside is that if std ever adds fallible methods later, they'd need to be replaced with wrappers in a breaking change.

In the case of Metadata, there already are several APIs which return std::fs::Metadata. When Metadata is wrapped, these should be switched to return the wrapper (breaking change).

@andrewhickman andrewhickman added the enhancement New feature or request label Sep 19, 2020
@Emerentius
Copy link
Contributor Author

Thinking about it, the re-exports don't add any new forwards-compatibility issues, at least so long as one wants to keep the API consistent and without any surprises.

If FileType were wrapped, then fs_err::DirEntry::file_type would also need to be changed. That's already a breaking change.
Similarly for Permissions, there are two set_permissions functions which take a Permissions struct which would need to be changed.

@andrewhickman
Copy link
Owner

DirBuilder would certainly make sense to wrap, especially since we already provider a wrapper for tokio::fs::DirBuilder.

It looks like the fallible methods on Metadata only fail if the platform doesn't support the operation - so arguably the path isn't relevant anyway. I dont think its worth a breaking change to wrap it, but I think a re-export is a good idea (and likewise for Permissions and FileType)

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

No branches or pull requests

2 participants