Copying with preserveTimeStamps: true is inaccurate using 32bit node

[CurryKitten]

I have been running the fs-extra tests via npm test on various platforms, and have been getting failures on the 32bit versions of node. I wasn't sure if millisecond precision would be supported or not at 32bits, and it should be pointed out that the underlying OS is 64bit, but we do get back valid millisecond precision timestamps using 32bit node, it's just not accurate once we copy a file and ask to preserve timestamps.

This can be reproduced using this small snippet of code -

var fs = require('fs')
var fse = require('fs-extra')
var from = './forcopy' 
var to = './copied'

fse.copySync(from, to, {preserveTimestamps: true})
var fromStat = fs.statSync(from)
var toStat = fs.statSync(to)
console.log('From stat: ' , fromStat.mtime.getTime())
console.log('To stat: ' , toStat.mtime.getTime())

if I then touch the forcopy file and then run with 64bit node

$ which node
~/node-v4.5.0-linux-x64/bin/node
$ node copyTest
From stat:  1472712683269
To stat:  1472712683269

and then with 32bit node

$ which node
~/node-v4.5.0-linux-x86/bin/node
$ node copyTest
From stat:  1472712683269
To stat:  1472712683208

I can replicate this problem on rhel7, sles12 and ubuntu 14-04

[RyanZim]

@jprichardson ?

[jprichardson]

@jprichardson ?

Ah, this could be a nasty one. Not sure how to proceed here as millisecond precision has been a bear.

[RyanZim]

@CurryKitten Does this problem directly affect your actual code?

If not, this is low-priority or wontfix IMO.

[hhamilto]

I did a little digging previously, and this issue is due to the limitations of floating point precision in 32 bit Node.js.

Internally, we implement the preserveTimestamps option by calling futimes on the new copy of the file. However, the interface for futimes that libuv exposes takes the timestamp as a double (and therefor does also Node.js) l, which limits the precision when running in 32 bit mode.

See here:
https://github.com/libuv/libuv/blob/v1.x/src/unix/fs.c#L154

As far as I can tell, we would need libuv to expose an alternate interface for futimes, and for node to then expose that interface to us.

[jprichardson]

Ah, sounds like maybe the best course of action is to throw up a warning if it's 32-bit and the flag is set.

[jprichardson]

Btw, thanks for your help here @hhamilto!

[RyanZim]

@jprichardson How should we pass this warning? console.warn? (bad practice for libs IMO)

[jprichardson]

console.warn? (bad practice for libs IMO)

I generally agree with this, but I don't know of any other way other than console.warn....

[RyanZim]

OK, sounds good.

Self-assigning but if someone else wants to do this, let me know.

[RyanZim]

@jprichardson What's the most accurate way to determine 32 or 64 bit?

[jprichardson]

Since we care about the Node.js build arch not the actual CPU arch (i.e. 32 bit Node can run on 32-bit or 64-bit arch), I think process.arch should be fine.

[RyanZim]

From the docs:

The current possible values are: 'arm', 'arm64', 'ia32', 'mips', 'mipsel', 'ppc', 'ppc64', 's390', 's390x', 'x32', 'x64', and 'x86'.

I wasn't quite sure which architectures were 32 bit. Obviously arm, ia32, ppc, s390 are 32-bit, not quite sure about mips, mipsel, and the x* line (other than x64 being 64-bit).

[jprichardson]

Great point. I was naively only thinking about ia32.

@CurryKitten you were referring to ia32, correct? Or any 32-bit Node.js

[CurryKitten]

@jprichardson I'm away on vacation at the moment, so don't have my notes with me - but I believe in this case it was just ia32 that exhibited this problem. From memory, zLinux31 was giving an issue, but it wasn't the same symptoms.

[RyanZim]

OK, I think I'll just warn for ia32; if other architectures have the same problem, we can add warnings for them later.