We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
Describe the bug
The LocalFileSystem fails to return data when a byte range starts before the end of the file.
LocalFileSystem
To Reproduce
#[tokio::test] async fn range_request_beyond_end_of_file() { let root = TempDir::new().unwrap(); let integration = LocalFileSystem::new_with_prefix(root.path()).unwrap(); let location = Path::from("some_file"); let data = Bytes::from("arbitrary data"); integration .put(&location, data.clone().into()) .await .unwrap(); let read_data = integration.get_range(&location, 0..100).await.unwrap(); assert_eq!(&*read_data, data); }
This currently fails with
called `Result::unwrap()` on an `Err` value: Generic { store: "LocalFileSystem", source: OutOfRange { path: "/private/var/folders/42/5jr6891d4ds4xysz7q0rsghw0000gn/T/.tmpK2eHCc/some_file", expected: 100, actual: 14 } }
Expected behavior
In line with the HTTP spec and other object stores, the LocalFileSystem should return the satisfiable part of the range request.
Additional context
Some discussion in Discord: https://discord.com/channels/885562378132000778/885562378132000781/1308082632898248836
The text was updated successfully, but these errors were encountered:
Successfully merging a pull request may close this issue.
Describe the bug
The
LocalFileSystem
fails to return data when a byte range starts before the end of the file.To Reproduce
This currently fails with
Expected behavior
In line with the HTTP spec and other object stores, the
LocalFileSystem
should return the satisfiable part of the range request.Additional context
Some discussion in Discord: https://discord.com/channels/885562378132000778/885562378132000781/1308082632898248836
The text was updated successfully, but these errors were encountered: