On filesystems which do not support birthtime, stats.birthtime can be greater than stats.mtime

[jorangreef]

stats.birthtime tracks ctime on filesystems which do not support birthtime, even if stats.ctime > stats.mtime or stats.ctime > stats.atime.

It would be better in this case if stats.birthtime be set to the earliest of all available timestamps.

Here is a test to reproduce, which should pass on OS X and fail on Ubuntu:

var fs = require('fs');
console.log('creating...');
try {
  fs.unlinkSync('testbirthtime');
} catch (error) {}
fs.writeFileSync('testbirthtime', '');
console.log('statting...');
var before = fs.statSync('testbirthtime');
if (before.mtime.getTime() === before.ctime.getTime() && before.ctime.getTime() === before.birthtime.getTime()) {
  console.log('stats.mtime===stats.ctime===stats.birthtime');
} else {
  console.log(JSON.stringify(before));
  // should never be here, unless the test is faulty.
  throw new Error('expected stats.mtime===stats.ctime===stats.birthtime after create');
}
// give enough time for filesystem timestamp granularity
console.log('waiting 3 seconds...');
setTimeout(
  function() {
    console.log('changing mode to bump ctime...');
    fs.chmodSync('testbirthtime', '777');
    console.log('statting again...');
    var after = fs.statSync('testbirthtime');
    try {
      fs.unlinkSync('testbirthtime');
    } catch (error) {}
    if (after.birthtime.getTime() === before.birthtime.getTime()) {
      console.log('===========');
      console.log('TEST PASSED');
      console.log('stats.birthtime stayed the same after chmod');
    } else {
      console.log('===========');
      console.log('TEST FAILED');
      console.log('stats.birthtime after chmod !== stats.birthtime at creation');
      if (after.birthtime.getTime() > before.birthtime.getTime()) {
        console.log('stats.birthtime has gone forward in time');
      } else {
        console.log('stats.birthtime has gone backward in time');
      }
      if (after.mtime.getTime() === before.mtime.getTime()) {
        console.log('stats.mtime stayed the same after chmod');
      }
      if (after.birthtime.getTime() === after.ctime.getTime()) {
        console.log('stats.birthtime now equals newer stats.ctime');
        console.log('where birthtime is not supported by filesystem:');
        console.log('  stats.birthtime should be earlier of stats.mtime and stats.ctime');
      }
    }
  },
  3000
);

[brendanashworth]

@jorangreef thanks for reporting this. I've submitted a patch to our upstream dependency, libuv, which will hopefully make its way into the node codebase and fix the problem for you!

[jorangreef]

Thanks for the patch @brendanashworth!

[ivan]

Why is it node's business to fabricate a birthtime when one isn't available? When Linux finally gains an API to look up the birth times that are already on the filesystem, will we need a birthTimesAreRealBirthTimes() API?

[brendanashworth]

We don't have to close it just yet - it is still pertinent! :)

Why is it node's business to fabricate a birthtime when one isn't available? When Linux finally gains an API to look up the birth times that are already on the filesystem, will we need a birthTimesAreRealBirthTimes() API?

Not quite node, but libuv wants to provide a consistent API on all platforms. You could open an issue there if you'd like.

[brendanashworth]

The upstream patch was not accepted because it broke backwards compatibility (and because it fabricated a birthtime when one wasn't available, wink @ivan).

@jorangreef I think the best way to solve this on the node.js side is a note in the documentation of fs.Stat. Would you be interested in sending a PR?

[jorangreef]

@brendanashworth sure, I will be away till next week.

[kthelgason]

@jorangreef still planing on sending a PR for this?

[jorangreef]

@kthelgason if you would like to that would be appreciated, otherwise I will.

[kthelgason]

Done. Thanks @jorangreef for raising the issue. You can view the change in #5479 and comment on whether you think this clarifies things.

[thefourtheye]

If this is going to be accepted as expected result, then I would recommend including a test as well. Perhaps the code in this issue would do?

[jorangreef]

Thanks @kthelgason !

@thefourtheye this is only a docs change for clarification, and it's possible in all environments for btime to be > than atime or mtime, so I don't think a test is needed.