-
-
Notifications
You must be signed in to change notification settings - Fork 31.4k
Incorrect slice() from fs.openAsBlob() #53908
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Labels
confirmed-bug
Issues with confirmed bugs.
fs
Issues and PRs related to the fs subsystem / file system.
Comments
Reproducible: import fs from 'node:fs';
// await fs.writeFile('file.txt', '123456789')
const blob = await fs.openAsBlob('file.txt');
console.log(await blob.text());
console.log(await blob.slice(3).text());
console.log(await blob.slice(3).slice().text());
|
It however does not occur with non-fs blobs: import { Blob } from 'node:buffer';
const blob = new Blob(['123456789']);
console.log(await blob.text());
console.log(await blob.slice(3).text());
console.log(await blob.slice(3).slice().text());
|
Hey @redyetidev, could you assign me this issue? I'd like to work on it, if that's alright. |
Feel free to work on it, but issues aren't typically assigned (except when they are self assigned). If you have an improvement, feel free to submit a PR. |
Line 854 in cf8e535
Should be: new_end = std::min(end.value() + start_, end_); |
Feel free to submit a PR with suggestions to the Conway. |
jleedev
added a commit
to jleedev/node
that referenced
this issue
Jul 20, 2024
The value for `new_end` was wrong: While the members `start_` and `end_` refer to the entire length of the file, the parameters `start` and `end` are relative to the current slice. The new end would apparently have the current start_ subtracted from it, and the length would possibly overflow when the FdEntry is asked for its size or when get_reader is called, resulting in a subslice which extends past the current slice, which shouldn't be possible. Add a CHECK if this happens, rather than returning data outside the current slice. There aren't any C++ tests for FdEntry, and on the javascript side there isn't a way to ask the blob handle for its nominal size. That size could be a large uint64, which gets converted to int64 to when FileHandle::new is called, which interprets a negative length as unlimited. Fixes: nodejs#53908
nodejs-github-bot
pushed a commit
that referenced
this issue
Jul 22, 2024
The value for `new_end` was wrong: While the members `start_` and `end_` refer to the entire length of the file, the parameters `start` and `end` are relative to the current slice. The new end would apparently have the current start_ subtracted from it, and the length would possibly overflow when the FdEntry is asked for its size or when get_reader is called, resulting in a subslice which extends past the current slice, which shouldn't be possible. Add a CHECK if this happens, rather than returning data outside the current slice. There aren't any C++ tests for FdEntry, and on the javascript side there isn't a way to ask the blob handle for its nominal size. That size could be a large uint64, which gets converted to int64 to when FileHandle::new is called, which interprets a negative length as unlimited. Fixes: #53908 PR-URL: #53972 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
targos
pushed a commit
that referenced
this issue
Jul 28, 2024
The value for `new_end` was wrong: While the members `start_` and `end_` refer to the entire length of the file, the parameters `start` and `end` are relative to the current slice. The new end would apparently have the current start_ subtracted from it, and the length would possibly overflow when the FdEntry is asked for its size or when get_reader is called, resulting in a subslice which extends past the current slice, which shouldn't be possible. Add a CHECK if this happens, rather than returning data outside the current slice. There aren't any C++ tests for FdEntry, and on the javascript side there isn't a way to ask the blob handle for its nominal size. That size could be a large uint64, which gets converted to int64 to when FileHandle::new is called, which interprets a negative length as unlimited. Fixes: #53908 PR-URL: #53972 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
RafaelGSS
pushed a commit
that referenced
this issue
Aug 5, 2024
The value for `new_end` was wrong: While the members `start_` and `end_` refer to the entire length of the file, the parameters `start` and `end` are relative to the current slice. The new end would apparently have the current start_ subtracted from it, and the length would possibly overflow when the FdEntry is asked for its size or when get_reader is called, resulting in a subslice which extends past the current slice, which shouldn't be possible. Add a CHECK if this happens, rather than returning data outside the current slice. There aren't any C++ tests for FdEntry, and on the javascript side there isn't a way to ask the blob handle for its nominal size. That size could be a large uint64, which gets converted to int64 to when FileHandle::new is called, which interprets a negative length as unlimited. Fixes: #53908 PR-URL: #53972 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
marco-ippolito
pushed a commit
that referenced
this issue
Aug 19, 2024
The value for `new_end` was wrong: While the members `start_` and `end_` refer to the entire length of the file, the parameters `start` and `end` are relative to the current slice. The new end would apparently have the current start_ subtracted from it, and the length would possibly overflow when the FdEntry is asked for its size or when get_reader is called, resulting in a subslice which extends past the current slice, which shouldn't be possible. Add a CHECK if this happens, rather than returning data outside the current slice. There aren't any C++ tests for FdEntry, and on the javascript side there isn't a way to ask the blob handle for its nominal size. That size could be a large uint64, which gets converted to int64 to when FileHandle::new is called, which interprets a negative length as unlimited. Fixes: #53908 PR-URL: #53972 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
marco-ippolito
pushed a commit
that referenced
this issue
Aug 19, 2024
The value for `new_end` was wrong: While the members `start_` and `end_` refer to the entire length of the file, the parameters `start` and `end` are relative to the current slice. The new end would apparently have the current start_ subtracted from it, and the length would possibly overflow when the FdEntry is asked for its size or when get_reader is called, resulting in a subslice which extends past the current slice, which shouldn't be possible. Add a CHECK if this happens, rather than returning data outside the current slice. There aren't any C++ tests for FdEntry, and on the javascript side there isn't a way to ask the blob handle for its nominal size. That size could be a large uint64, which gets converted to int64 to when FileHandle::new is called, which interprets a negative length as unlimited. Fixes: #53908 PR-URL: #53972 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
marco-ippolito
pushed a commit
that referenced
this issue
Aug 19, 2024
The value for `new_end` was wrong: While the members `start_` and `end_` refer to the entire length of the file, the parameters `start` and `end` are relative to the current slice. The new end would apparently have the current start_ subtracted from it, and the length would possibly overflow when the FdEntry is asked for its size or when get_reader is called, resulting in a subslice which extends past the current slice, which shouldn't be possible. Add a CHECK if this happens, rather than returning data outside the current slice. There aren't any C++ tests for FdEntry, and on the javascript side there isn't a way to ask the blob handle for its nominal size. That size could be a large uint64, which gets converted to int64 to when FileHandle::new is called, which interprets a negative length as unlimited. Fixes: #53908 PR-URL: #53972 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Labels
confirmed-bug
Issues with confirmed bugs.
fs
Issues and PRs related to the fs subsystem / file system.
Version
v22.5.0
Platform
Subsystem
No response
What steps will reproduce the bug?
How often does it reproduce? Is there a required condition?
No response
What is the expected behavior? Why is that the expected behavior?
slice()
with no arguments should be equivalent toslice(0, length)
and return the entire blob; both of those are incorrectly returning something else.What do you see instead?
The returned
Blob
object purports to have the expectedsize
, but when it is read it has the wrong length.Additional information
No response
The text was updated successfully, but these errors were encountered: