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

Cannot call fsync on tokio::fs::File #40

Open
tsturzl opened this issue Jan 20, 2021 · 0 comments
Open

Cannot call fsync on tokio::fs::File #40

tsturzl opened this issue Jan 20, 2021 · 0 comments

Comments

@tsturzl
Copy link

tsturzl commented Jan 20, 2021

Hey there, first of all I have to say great work with this project. It's probably one of the most intuitive uring libraries out there. I've been working on a project using Rio along with Tokio. I'm using Rio both for file and network IO, and I noticed that most functions such as write_at take any type which implements AsRawFd, however some functions such as fsync explicitly take the std::fs::File type. I'm currently using tokio's File type(tokio::fs::File), since there are some file operations like retrieving metadata that I'd like to do asynchronously which isn't supported by Rio. I'm assuming you only accept a std::fs::File since you'd only ever expect to fsync a file rather than a socket, however this means I have to do some ugliness to use a tokio File type. Currently my work around for this is to grab the raw file descriptor from the tokio file and create a std file out of that descriptor, I don't believe this is any less safe than what Rio is doing, but it's kind of a pain. I'm wondering if you'd accept a PR that changed the couple of functions that expect Files to allow any type that implements AsRawFd, or if you find it concerning that this is potentially less safe or prone to misuse since then you can technically pass in something like a socket.

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

No branches or pull requests

1 participant