fs: expose Stats times as Numbers#13173
Conversation
test/parallel/test-fs-stat.js
Outdated
There was a problem hiding this comment.
nit: I think just parsed or similar would be a better variable name.
test/parallel/test-fs-stat.js
Outdated
There was a problem hiding this comment.
Single quotes should be used for string literals.
There was a problem hiding this comment.
These tests are failing because they're using "atime_msec" rather than "atim_msec", btw.
lib/fs.js
Outdated
There was a problem hiding this comment.
Also, can we change these names to add the missing 'e' (e.g. atim_msec -> atime_msec)?
There was a problem hiding this comment.
I feel like snake_case is pretty uncommon in node, so should maybe be changed.. but mtimeMsec is kinda ugly, so I'm not going to suggest it.
There was a problem hiding this comment.
I agree and tend to favor camel-case for js stuff, but I'm not sure about it in this case. I guess it's because the second part is an abbreviation. mtimeMs looks a little better though.
There was a problem hiding this comment.
Just so you know, this is/was named this way because it derives from the POSIX stat struct that has existed with these names for a long time; I think it’s okay to keep the underscore here.
There was a problem hiding this comment.
isn't posix just atim, mtim and ctim? but sure, timespec has tv_nsec etc.. and it doesn't matter.
There was a problem hiding this comment.
I guess, yeah. If you want to go with mtimeMs, I’m not going to stand in your way or anything :)
There was a problem hiding this comment.
@refack can decide, i'm good with whatever he prefers.
There was a problem hiding this comment.
We've had the posix/non-posix discussion before for another feature in core, although I think that PR ended up dying because we couldn't decide ;-)
There was a problem hiding this comment.
Went with camelCase Ms suffix.
|
LGTM once @mscdex’s comments have been addressed. Also, CI failure (I assume that would fail with a local |
lib/fs.js
Outdated
There was a problem hiding this comment.
Should these not get this.birthtim_msec etc instead of the Date values?
There was a problem hiding this comment.
Yep, they should be birthtime_msec, etc.
There was a problem hiding this comment.
atime_msec: this._atime || atime_msec: this.atime would be better?`
Ack
There was a problem hiding this comment.
Should just be, atime_msec: this.atime_msec,, I think? this is in the toJSON function, so I figure it should just expose that value.
@addaleax Sorry I didn't label this |
doc/api/fs.md
Outdated
There was a problem hiding this comment.
I'll fix this after the CI passes
doc/api/fs.md
Outdated
test/parallel/test-fs-stat.js
Outdated
There was a problem hiding this comment.
Really tiny nit, but could you pick a different name for this variable.
There was a problem hiding this comment.
Since the name I came up with is numerFields I decided to add all the number fields, so 👍
test/parallel/test-fs-stat.js
Outdated
There was a problem hiding this comment.
"should a" -> "should be a"
There was a problem hiding this comment.
Ack.
But we both missed the bug: typeof s.birthtimeMs was not parameterized 🤦♂️
doc/api/fs.md
Outdated
There was a problem hiding this comment.
These values don't agree with the Date-based fields shown below here.
There was a problem hiding this comment.
Ack.
But that's a very nice nit 😄
doc/api/fs.md
Outdated
There was a problem hiding this comment.
nit: s/instances of/instances of the/
There was a problem hiding this comment.
Ack.
(That was there before, I just had to rewrap because of **Note:**)
doc/api/fs.md
Outdated
There was a problem hiding this comment.
Perhaps this note about using .getTime() on the Date-based fields should be changed to suggest using the .*Ms fields instead.
There was a problem hiding this comment.
Or maybe this whole paragraph should be rewritten to make note of the .*Ms fields first and then simply say that the non--Ms fields are simply Dates that use the .*Ms values? Hopefully that would simplify the wording a bit?
There was a problem hiding this comment.
But Dates are easier to mutate, hence the bug.
doc/api/fs.md
Outdated
doc/api/fs.md
Outdated
There was a problem hiding this comment.
s/times/times in milliseconds/.
lib/fs.js
Outdated
There was a problem hiding this comment.
This isn't right. We should have tests to cover these to make sure the fields are what they should be.
There was a problem hiding this comment.
Removed this low quality optimization all together.
|
@mscdex and others. I've found a design bug: set(value) {
this.atimeMs = Number(value);
return this._atime = value;
}but mutations like const old = s.mtime;
s.mtimeMs = newValue;
s.mtimeMs !== s.mtime;
s.mtime === old; |
|
I would just make note of it in the documentation that they are not linked together and are merely separate values that are initialized using the same set of data. Making the |
Just realized that we don't accept a |
573025e to
c1210b4
Compare
lib/fs.js
Outdated
There was a problem hiding this comment.
I don't think this is a good idea since we don't update _ctime when ctimeMs is changed by end users and as I mentioned earlier, setting up a getter and setter for each number field to be able to do bidirectional updating is going to add noticeable overhead.
There was a problem hiding this comment.
So you suggest break the connection completely, instead of this one way idiosyncrasy?
... thinking ...
Ok. Makes sense. (also congruent with the Note:)
There was a problem hiding this comment.
Yes, that is what I'm suggesting.
lib/fs.js
Outdated
There was a problem hiding this comment.
I’m pretty sure the linter complains about this; also, prefer the value() { return this.toJSON(); } shorthand
There was a problem hiding this comment.
It's doesn't, but Ack.
I wanted to ask about the general approach of adding a [util.inspect.custom], is it Ok?
There was a problem hiding this comment.
I wanted to ask about the general approach of adding a [util.inspect.custom], is it Ok?
Yes, I think that makes sense.
There was a problem hiding this comment.
P.S. shorthand form lexical binds this so it should be linted for.
|
|
|
"Dry run" CI:https://ci.nodejs.org/job/node-test-commit/10276/ |
|
ping @mscdex @sciolist @thefourtheye @cjihrig @addaleax |
|
LGTM if CI is ok: https://ci.nodejs.org/job/node-test-pull-request/8494/ |
d8525d7 to
cedc47d
Compare
PR-URL: nodejs#13173 Fixes: nodejs#8276 Refs: nodejs#12607 Refs: nodejs#12818 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Brian White <mscdex@mscdex.net>
cedc47d to
47b9772
Compare
|
Landed in 47b9772 |
|
Extra sanity run on |
* **Async Hooks**
* When one `Promise` leads to the creation of a new `Promise`, the parent
`Promise` will be identified as the trigger
[[`135f4e6643`](nodejs@135f4e6643)]
[nodejs#13367](nodejs#13367).
* **Dependencies**
* libuv has been updated to 1.12.0
[[`968596ec77`](nodejs@968596ec77)]
[nodejs#13306](nodejs#13306).
* npm has been updated to 5.0.3
[[`ffa7debd7a`](nodejs@ffa7debd7a)]
[nodejs#13487](nodejs#13487).
* **File system**
* The `fs.exists()` function now works correctly with `util.promisify()`
[[`6e0eccd7a1`](nodejs@6e0eccd7a1)]
[nodejs#13316](nodejs#13316).
* fs.Stats times are now also available as numbers
[[`c756efb25a`](nodejs@c756efb25a)]
[nodejs#13173](nodejs#13173).
* **Inspector**
* It is now possible to bind to a random port using `--inspect=0`
[[`cc6ec2fb27`](nodejs@cc6ec2fb27)]
[nodejs#5025](nodejs#5025).
* **Zlib**
* A regression in the Zlib module that made it impossible to properly
subclasses `zlib.Deflate` and other Zlib classes has been fixed.
[[`6aeb555cc4`](nodejs@6aeb555cc4)]
[nodejs#13374](nodejs#13374).
* **Async Hooks**
* When one `Promise` leads to the creation of a new `Promise`, the parent
`Promise` will be identified as the trigger
[[`135f4e6643`](135f4e6643)]
[#13367](#13367).
* **Dependencies**
* libuv has been updated to 1.12.0
[[`968596ec77`](968596ec77)]
[#13306](#13306).
* npm has been updated to 5.0.3
[[`ffa7debd7a`](ffa7debd7a)]
[#13487](#13487).
* **File system**
* The `fs.exists()` function now works correctly with `util.promisify()`
[[`6e0eccd7a1`](6e0eccd7a1)]
[#13316](#13316).
* fs.Stats times are now also available as numbers
[[`c756efb25a`](c756efb25a)]
[#13173](#13173).
* **Inspector**
* It is now possible to bind to a random port using `--inspect=0`
[[`cc6ec2fb27`](cc6ec2fb27)]
[#5025](#5025).
* **Zlib**
* A regression in the Zlib module that made it impossible to properly
subclasses `zlib.Deflate` and other Zlib classes has been fixed.
[[`6aeb555cc4`](6aeb555cc4)]
[#13374](#13374).
* **Async Hooks**
* When one `Promise` leads to the creation of a new `Promise`, the parent
`Promise` will be identified as the trigger
[[`135f4e6643`](135f4e6643)]
[#13367](#13367).
* **Dependencies**
* libuv has been updated to 1.12.0
[[`968596ec77`](968596ec77)]
[#13306](#13306).
* npm has been updated to 5.0.3
[[`ffa7debd7a`](ffa7debd7a)]
[#13487](#13487).
* **File system**
* The `fs.exists()` function now works correctly with `util.promisify()`
[[`6e0eccd7a1`](6e0eccd7a1)]
[#13316](#13316).
* fs.Stats times are now also available as numbers
[[`c756efb25a`](c756efb25a)]
[#13173](#13173).
* **Inspector**
* It is now possible to bind to a random port using `--inspect=0`
[[`cc6ec2fb27`](cc6ec2fb27)]
[#5025](#5025).
* **Zlib**
* A regression in the Zlib module that made it impossible to properly
subclasses `zlib.Deflate` and other Zlib classes has been fixed.
[[`6aeb555cc4`](6aeb555cc4)]
[#13374](#13374).
|
@nodejs/lts should we backport this to v6.x in a future minor? |
|
This is a follow-on to #12818, which is semver-major, so unbackportable. But, this PR seems to try to make things more "backwards" compatible, right, by adding accessor properties? I think doing that kind of thing has itself been considered semver-major in the past. Or perhaps I'm a bit lost in all the related issues, and also don't have time to read the epic commentary on this PR. @refack what is the case for this being safe to backport? what are its dependent PRs, if any? |
|
It's not based on #12818, there just used to be a reference to it in some documentation. #12818 was reverted as it caused issues that were likely not fixable. This PR indirectly depends on #13281 and #12607. (It will work without them, just won't be very useful.) What it does is expose a few extra numbers on the Stats object, I don't think there's much reason to believe it's unsafe. |
|
@nodejs/lts Adding fields to a object returned by node (stats) could confuse some existing code if it was very poorly written, but it is good to keep API continuity between 6.x and later. I think I'm +1. What do you all think? |
Expose Stats times as Numbers
also set Date cache fields in constructor
Fixes: #8276
Fixes: npm/npm#16734
Ref: #12607
Ref: #12818
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passesAffected core subsystem(s)
fs