stale option fix for windows file tunneling

[jsstorm]

Stale option fix for windows file tunneling: https://github.com/isaacs/lockfile/issues/2

[isaacs]

Are the tests currently failing? If not, please add a test for this that fails without the fix.

[jsstorm]

2 spaces intent now, added test for the windows file tunneling.

mtime and atime both works, but i did some quick tests and still prefer mtime:

on windows system: file operations write or append to the file won't update the file access time, but modification time will be updated correctly. read the file won't update modification time or access time.

mtime and atime is equal if the file isn't used by other programs (should be avoided), and the patch is for windows only, other platforms will still use ctime as before.

btw: the old test ‘wait and stale together’ will also fail on windows for the same tunneling problem. touch.sync() only updates file modification time and access time on windows, but will also update the file creation time on linux. this patch will fix it too, but the it reminds that touch.sync() can cause some problem on windows if you depend on it to update file creation time.

[jsstorm]

I reconsidered for mtime and atime, if you want some timestamp more like ctime (won't be changed after file creation), then use atime is better, if you want to know other program modified the lock file and consider that as lock updating, then you can use mtime, the atime patch is also commited

[isaacs]

I'm fine with either mtime or atime. Your reasoning makes sense. I'll review and land shortly.

The confusion, of course, is that "ctime" is not "creation time" on Unix -- it's "change time", as in, "the time that the inode metadata was last changed".

Related: https://github.com/joyent/libuv/issues/901