`FdEntry::Create()` returned nullptr for any failed `uv_fs_stat()`,
discarding the status, and `BlobFromFilePath()` turned that into
`ERR_INVALID_ARG_VALUE: Unable to open file as blob`. A missing file is
not a malformed argument, and the resulting `TypeError` carried no
`errno`, `syscall`, or `path`, so ENOENT could not be told apart from
any other reason the path was unusable.
Thread the libuv status out of `CreateFdEntry()` and throw a
`UVException` instead, so `fs.openAsBlob()` reports the same error
`fs.stat()` does for the same path.
Fixes: https://github.com/nodejs/node/issues/65514
Signed-off-by: Paul Bouchon <mail@bitpshr.net>
PR-URL: https://github.com/nodejs/node/pull/65517
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
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: https://github.com/nodejs/node/issues/53908
PR-URL: https://github.com/nodejs/node/pull/53972
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Noah