Skip to content

clarify the position argument for fs.read #14612

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.

Sign up for GitHub

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

Closed
wants to merge 2 commits into from
Closed

clarify the position argument for fs.read #14612

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
04d1ca0
clarify the position argument for fs.read
dcharbonnier Aug 3, 2017
ad9134f
fix typo
dcharbonnier Aug 3, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion doc/api/fs.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1640,7 +1640,9 @@ Read data from the file specified by `fd`.
`length` is an integer specifying the number of bytes to read.

`position` is an integer specifying where to begin reading from in the file.
Copy link
Contributor

@sam-github sam-github Aug 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest "is an argument", its not always an integer, null is not an integer

Copy link
Contributor Author

@dcharbonnier dcharbonnier Aug 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#14621

If `position` is `null`, data will be read from the current file position.
If `position` is `null`, data will be read from the current file position,
and the file position will be updated for subsequent reads.
Copy link
Contributor

@sam-github sam-github Aug 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is only one current file position, its used for read and for write, but this makes it sound like its used only for reads. I would just say the current file position is updated.

Copy link
Contributor Author

@dcharbonnier dcharbonnier Aug 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's pretty obvious that there is only one file position, this "for subsequent reads" was to ring a bell.
You can put "operation" instead of "read" but in this case it will ring no bell.
What need to be clarified is that what happen to the position in the descriptor is different if the value is null, the documentation was saying nothing about this and so I (and I'm not the only one, see the issue) was assuming that the behavior was the same in both cases.
The current documentation is not saying anything about the fact that there is only one file position, I don't get why we should start mentioning it. How many times do you do a read/write ? Don't you thing that when people do this they already have a pretty god idea of the fact that there is one cursor in the file descriptor ? And that they would find strange that there would be one for read and one for write ?

Copy link
Member

@jasnell jasnell Aug 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sam-github's concern here can be addressed with a simple edit here...

If `position` is `null`, data will be read from the current file position,
and the file position will be updated.

If `position` is an integer, the file position will remain unchanged.
Copy link
Contributor

@sam-github sam-github Aug 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe it feels obvious, but for null you say where it reads from (current position) and what happens to current position (its updated). For the integer case this says file position is unchange, but it doesn't say where read is from, which is from the integer as a positive offset from beginning of file (-4 won't read from 4 bytes before end of file, for example).

also, the file position will be changed on Windows, though there is a UV PR to change windows to be like unix: libuv/libuv#1357, not sure if that has effected node yet, though.

Copy link
Contributor

@cjihrig cjihrig Aug 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like that PR landed in libuv 1.13.0, so it has at least made its way to Node.

Copy link
Contributor Author

@dcharbonnier dcharbonnier Aug 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah and let's say what happen if you have a position that goes over the size of the file and specify that it's bytes, also say that the position in the end is the quantity that has been read + the previous position but let's wait that you do it on an other PR because this has noting to do with this one


The callback is given the three arguments, `(err, bytesRead, buffer)`.

Expand Down