.dest : mtime/atime lose sub-second precision

[erikkemperman]

When .dest writes to file, the atime and mtime get rounded (well, floored) to seconds, even when the filesystem supports subsecond precision.

Example gulpfile.js:

// Bogus plugin to print mtimes
function meta() {
  return through.obj(function( file, enc, cb) {
    console.log(file.stat.mtime.valueOf());
    this.push(file);
    cb();
  });
}

gulp.task('test1', function() {
  return gulp.src('./src/foo.js')
    .pipe(meta())
    .pipe(gulp.dest('./dist/'))
});

gulp.task('test2', function() {
  return gulp.src('./dist/foo.js')
    .pipe(meta());
});

gulp.task('default', gulp.series('test1', 'test2'));

the above would output something like this:

[17:09:00] Starting 'default'...
[17:09:00] Starting 'test1'...
1442829863383
[17:09:00] Finished 'test1' after 22 ms
[17:09:00] Starting 'test2'...
1442829863000
[17:09:00] Finished 'test2' after 4.88 ms
[17:09:00] Finished 'default' after 29 ms

This is problematic when using plugins like gulp-changed or gulp-newer, e.g. when we want to copy source files to a dist directory only if they've changed.

I've tracked this down to the fact that fs.utimes is called. Apparently the problem would go away if fs.futimes were called, see here. I just did some quick-and-dirty experimenting which confirms that this is the case.

Even better, I suppose, would be to fix utimes, see here, but I think that might not happen any time soon.

I'd be willing to make a PR which would make vinyl-fs use futimes but wanted to check first if this sounds like a good idea, or maybe there might be other solutions I'm overlooking.

[phated]

@erikkemperman in the linked node issue, it says there is a caveat of filesystems that don't support subsecond resolution. What does futimes do in those cases?

[erikkemperman]

@phated I think he's just saying that using fs.futimes in stead of fs.utimes won't solve your problem of retaining fractions of a second -- if the filesystem you have underneath doesn't support it. I have no fs at hand to test this case... But surely no fs will cause the atime and mtime to be in seconds, in stead of millis, or something like that?

[phated]

I'll try to run the tests on windows to see what happens. Think I have a VM lying around somewhere.

[erikkemperman]

With a FAT partition? NTFS would not have this problem, right?

I'm curious how that turns out. My guess is it will just work as if every read/write happened at precisely .000 millis, which is pretty much what it did before my patch.

[phated]

Blah, no luck with that VM. I'm going to get this merged under the assumption it just rounds 😛

[erikkemperman]

Probably not too many people use an fs which might be affected...? Famous last words.

Anyway, great if it got merged!

[phated]

@erikkemperman just needs a rebase (commented on PR)

[phated]

Closed by #125 - grouping some other fixes in a release.