-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
[WasmFS] Allow move
to return specific error codes
#17785
Conversation
Update the return type of `getSize` from `size_t` to `off_t`, which allows for negative error codes. `off_t` is more correct anyway, since in 32-bit mode it is possible for a file size to be greater than the max value of `size_t`. Also update the argument to `getSize` from `size_t` to `off_t` to match. I manually verified that this error handling works with an injected error, but I was not able to create a test that could trigger the error naturally.
It already supporting returning errors via a `bool`, but it is better to be able to return precise errors. Also catch and return errors in the OPFS backend, which did not previously do any error handling for moves. Tested manually via an error injected into the OPFS backend since I don't know a way to get the `move` method on the FileSystemFileHandle to reliably fail in a way that wouldn't cause the syscall implementation to bail out earlier.
Current dependencies on/for this PR:
This comment was auto-generated by Graphite. |
if (!lockedNewParent.insertMove(newFileName, oldFile)) { | ||
return -EPERM; | ||
if (auto err = lockedNewParent.insertMove(newFileName, oldFile)) { | ||
return err; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe in places like this it would be good to assert(err < 0)
? (otherwise we are just checking != 0
). One other place above too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done separately in #17786
It already supporting returning errors via a
bool
, but it is better to be ableto return precise errors. Also catch and return errors in the OPFS backend,
which did not previously do any error handling for moves.
Tested manually via an error injected into the OPFS backend since I don't know a
way to get the
move
method on the FileSystemFileHandle to reliably fail in away that wouldn't cause the syscall implementation to bail out earlier.