Repository navigation
regression: fs.utimes/futimes for dates before unix epoch #14017
Description
Activity
- addedfsIssues and PRs related to file-system APIs and the fs module.Issues and PRs related to file-system APIs and the fs module.
on Jul 1, 2017 @isaacs is this recently introduced in v4.8.3? Is there an earlier version of v4.x where this is not happening?
It was introduced in #2387 (specifically in #2387 (comment)), backported to version 4.1.0. In other words, only version 4.0.0 in the v4.x branch is not affected by the bug.
@gireeshpunathil that was a doc update about Infinity and NaN. Are you certain you referenced the correct PR? #15680 is independent from this issue as far as I can tell.
probably not - I was just following the linked references.
An observation: On specifying a negative timestamp as a string for values before 1970-01-01T00:00:00.000Z the atime and utime were modified correctly (https://nodejs.org/api/fs.html#fs_fs_utimes_path_atime_mtime_callback).
> fs.utimes('random.txt','-9999999999.0','-9999999999.0', function(){}) >.exit $ stat -x random.txt File: "random.txt" Size: 0 FileType: Regular File Device: 1,4 Inode: 69235639 Links: 1 Access: Mon Feb 10 12:06:41 1653 Modify: Mon Feb 10 12:06:41 1653 Change: Fri Oct 5 01:30:49 2018Should we document this or figure out a way to fix it? Thanks.
I also cannot reproduce. The example above works fine on node
masterso I guess it was fixed some time since 4.x. This won't be fixed in 4.x, of course, since that branch has been sunset.
As of Node v4, fs.utimes and fs.utimes are truncating the atime and mtime values to a positive integer.
This is incorrect, and makes it impossible to set atime and mtime values before 1970-01-01T00:00:00.000Z without creating a Date object.
It looks like this is the culprit: