-
Notifications
You must be signed in to change notification settings - Fork 30.8k
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.
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
utimes doesn't seem to support subseconds times #22070
Comments
@arcanis Are you sure this affects Linux? What version of MacOS did you test? If you tested one that has APFS, are you sure you aren't running into this MacOS APFS Driver bug? - https://openradar.appspot.com/radar?id=4978184932032512 |
* Revert "fix(util/fs): use file content instead of mtime to determine equality (#6010)" This reverts commit c53d039. * Bumps the cache version * Forces the mtime to be based on the time the archives got fetched * Fixes subseconds time assignment (nodejs/node#22070) * Adds regression tests for #5723 * Fixes tests * Fixes test on architectures that don't support subsecond precision
* Revert "fix(util/fs): use file content instead of mtime to determine equality (#6010)" This reverts commit c53d039. * Bumps the cache version * Forces the mtime to be based on the time the archives got fetched * Fixes subseconds time assignment (nodejs/node#22070) * Adds regression tests for #5723 * Fixes tests * Fixes test on architectures that don't support subsecond precision
@Fishrock123 I'll double check, but I'm pretty sure. Can't say the exact MacOS release, but I don't believe I was affected by the bug you mentioned (simply because Tracking down the issue, it seems to be that the Lines 700 to 705 in 537a4ba
|
Yeah, I also saw that while debugging my problem. I'll try to get a libuv pr up this week. |
This should improve uv_fs_utime resolution and reliability, as utime(2)'s precision is left more to the implementing platform than the newer but well supported alternatives. Related to nodejs/node#22070
This should improve uv_fs_utime resolution and reliability, as utime(2)'s precision is left more to the implementing platform than the newer but well supported alternatives. Related to nodejs/node#22070
This should improve uv_fs_utime resolution and reliability, as utime(2)'s precision is left more to the implementing platform than the newer but well supported alternatives. Related to nodejs/node#22070 PR-URL: libuv#1940
This should improve uv_fs_utime resolution and reliability, as utime(2)'s precision is left more to the implementing platform than the newer but well supported alternatives. Related to nodejs/node#22070 PR-URL: #1940 Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Libuv PR has been merged: libuv/libuv#1940 - should fix it but never got to actually trying if it solves this. 😅 |
@arcanis can you confirm if your problem is solved with the latest on master (including libuv 1.23.1)? |
I can confirm this is fixed. \o/ Fixed in 2790db5#diff-e8b03d17fba605de23431c53172682a5 / #22997 / Node 11.0.0 |
Not sure if it's an implementation issue or a documentation issue, but the following is unexpected:
As you can see, the precision is lost (my systems support subsecond precisions -
touch
manages to change them, and both thestat
utility andfs.stat
can read them without issues).The Node documentation also doesn't mention that
utimes
has a different behavior fromfutimes
(it actually suggest they share the exact same behavior, sincefutimes
redirect toutimes
), except possibly in this archived post.Additionally, the function name (
utimes
) seem to match the behavior of 2utime
instead of 3utimes
, which seems counterintuitive. The libuv implementation is calleduv_fs_utime
, which at least hints at the difference of behavior (except that they useuv_fs_futime
instead ofuv_fs_futimes
..).The text was updated successfully, but these errors were encountered: