Does not work with grunt-contrib-copy due to the timestamp precision disagreement

[Determinant]

As I tried, when specify newer:copy, the files will be copied no matter whether it gets modified. As I have observed, grunt-contrib-copy uses fs.utimesSync(dest, stat.atime, stat.mtime); to sync the timestamp, which only gives second-level precision (can be reproduced by first using grunt-contrib-copy to copy the file and then stat the original file and the copied version to see). And I think grunt-newer uses more strict comparison which is based on the millisecond-level precision. I don't know this should be either a bug or a feature enhancement for either package, but it would be great if they can work together.

[guigrpa]

I've also seen this behaviour

[masi]

Noticed that too, though others think that it has a different reason: https://github.com/tschaub/grunt-newer/issues/84

[parkersweb]

Interesting - we've got the same project set up on two different machines - one running OSX (El Capitain) and one running Windows 10.

Newer works correctly with contrib-copy on the OSX machine, but copies all the files every time on the windows machine. So - perhaps the timestamp comparison is different on the two OS?

[masi]

I don't know if that is the cause, but timestamps differ on file systems (FAT vs NTSF vs ext3 vs ...). The precision varies (from 10ms to 500ms or so, even more on older FS like FAT), so it is not a valid approach to compare OS time (in ms) from the system clock with FS timestamps.

[tschaub]

If someone is able to set up a simple example that reproduces the problem, it will be easier to dig in to. This would include a complete grunt config with nothing unrelated to the problem, a list of steps, and a description of what you get vs. what you expect.

[giovannipds]

Hi @tschaub. Is this what you need? https://github.com/giovannipds/grunt-newer-copy-test - hope to help somehow. :tongue:

[tschaub]

Thanks for the example @giovannipds.

When I run your example on OS X, things work as expected. I touch one file, and I get this:

$ touch src/file1.html 

>> File "src/file1.html" changed.
Running "newer:copy:htmls" (newer) task

Running "copy:htmls" (copy) task
Copied 1 file

This is with the following:

• grunt-cli@0.1.13
• grunt@0.4.5
• grunt-contrib-copy@0.8.2
• grunt-newer@1.1.2

Is anyone else able to reproduce this problem with the above setup?

[giovannipds]

Sounds like my example was using grunt-newer 1.1.1, but I don't if this makes any difference or if it's because of the OS (Win 10 here). Can somebody else try what @tschaub proposed? @masi, @parkersweb, @guigrpa or @Determinant? Just clone the repo I suggested above and pay attention to the grunt-newer version.

[parkersweb]

We've run the test project from @giovannipds on both OSX (El Capitain) and Windows 10. On OSX it copies just the modified file; on Windows 10 it copies all three files. In both cases we're running grunt-newer 1.1.2

[giovannipds]

Thanks @parkersweb. So the problem is the OS. Can someone else test in another Windows version? Just to be sure that the problem persists.

[giovannipds]

I think if we already know this limitation, we should put it in the "Known limitations" at the README. At least until the problem can be solved (if it'll be).

[jorrit]

When I use newer:imagemin on Windows the numeric times of the source and destination file are for instance 1454402410902 and 1454402410000. The stats.mtime > time check in anyNewer is always true because of this. Perhaps a simple division by 1000 and rounding down is in order?

[masi]

Granularity depends on the FS not the OS:

FAT - 2 seconds exFAT - 10 milliseconds NTFS - 100 nanoseconds EXT2 - 1 second EXT3 - 1 second EXT4 - 1 nanosecond ...

[jorrit]

Would a user-configurable maximum deviation be an idea? I could set it to 1 second and it would be fine.

[tschaub]

@jorrit sounds like a sensible idea.

[tschaub]

New tolerance option available in grunt-newer@1.2.0. Thanks @jorrit. See #94 for details.

[parkersweb]

Thanks so much @tschaub, @giovannipds and @jorrit - we're using the updated version with a tolerance of 1000 and its resolved the Windows platform issues we were seeing!