-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix syncing utimes if copied files #268
Conversation
Doesn't seem to work on Windows.
|
Fixed file open mode for windows platform (it requires 'r+' mode to be able to change utimes, linux requires dirs to be opened with 'r' only). Unfortunately, the tests will not work on windows platform:
|
We could skip the test on Windows as long as things work even without the subsecond precision. |
@@ -14,6 +14,7 @@ module.exports = function(grunt) { | |||
var fs = require('fs'); | |||
var chalk = require('chalk'); | |||
var fileSyncCmp = require('file-sync-cmp'); | |||
var isWindows = /^win/.test(process.platform); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be: var isWindows = process.platform === 'win32';
And yes, it's win32 for 64-bit too.
@shama @vladikoff: any ideas how we should proceed with this? |
I'm good with skipping that test on Windows for now and merging this. |
@nalajcie: can you rebase and squash the patches? Maybe leave nalajcie@99dded8 as a separate one though. |
fs.utimesSync saves times with one second precision, while fs.statSync gives us microsecond precision. This makes utimes not synchronized on filesystems with sub-second atime/ctime/mtime precision. Upgraded to use newer fs.futimesSync interface providing correct precision.
This test will not pass until it would be fixed in nodejs See: nodejs/node#2069
fix syncing utimes if copied files
Thanks! |
So the issue on windows will persist? |
@krnlde This is an issue with our testing on Windows. Are you running into a syncing utime issue on Windows? |
Yes. I updated to 1.0.0 today but that didn't help. There are also a few tickets in grunt newer. They are not sure where it comes from. And so am I. For the record: |
@krnlde if you can provide a repo that includes the minimum needed to reproduce your problem, that would be helpful. I tried https://github.com/giovannipds/grunt-newer-copy-test and this works as expected on OS X with It would also be good to know if the changes in |
Hey @tschaub sorry I missed your response. As stated in tschaub/grunt-newer#86 it should not be possible to reproduce this outside Windows. They (you) implemented a Regarding the repo to reproduce the behavior (on Windows): we are using it in https://github.com/micromata/bootstrap-kickstart . Unfortunately this is not the minimum needed setup you requested. But I don't have time to create one right now. Does this work for you anyway? |
Hi, while testing this module as part of the debian packaging effort, we noticed timestamp failures on i386 and armhf architectures. This is on:
For more details see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861515 |
@simevo: the issue shouldn't happen in the latest release. So if it still happens, there must be a difference in how the OS handles times. The main change in this PR is 217819f#diff-951068604e1c942635e6a1f96a88994dL122 |
We're on grunt-contrib-copy v1.0.0 and we have the commit you mention. I have reproduced the issue on a i386 lxc container running debian sid within a amd64 debian host running strecth, as follows:
this is what I get:
additional info:
|
What happens with a newer node version?
…On May 2, 2017 13:19, "simevo" ***@***.***> wrote:
We're on grunt-contrib-copy v1.0.0 and we have the commit you mention. I
have reproduced the issue on a i386 lxc container running debian sid within
a amd64 debian host running strecth, as follows:
apt install wget xz-utils git
cd /opt
wget https://nodejs.org/download/release/v4.8.2/node-v4.8.2-linux-x86.tar.xz
xz -d node-v4.8.2-linux-x86.tar.xz
tar xf node-v4.8.2-linux-x86.tar
rm node-v4.8.2-linux-x86.tar
echo 'export PATH=/opt/node-v4.8.2-linux-x86/bin:$PATH' >> ~/.bashrc
source ~/.bashrc
cd
git clone https://github.com/gruntjs/grunt-contrib-copy.git
cd grunt-contrib-copy
npm install grunt chalk file-sync-cmp jshint grunt-contrib-jshint grunt-contrib-clean grunt-contrib-nodeunit grunt-contrib-internal
grunt test
this is what I get:
Running "nodeunit:tests" (nodeunit) task
Testing copy_test.js.......F.
>> copy - timestampEqual
>> Error: 1493719861389 == 1493719861494
>> at Object.exports.copy.timestampEqual (test/copy_test.js:92:10)
>> at processImmediate [as _immediateCallback] (timers.js:396:17)
>> copy - timestampEqual
>> Error: 1493719861389 == 1493719861494
>> at Object.exports.copy.timestampEqual (test/copy_test.js:93:10)
>> at processImmediate [as _immediateCallback] (timers.js:396:17)
Warning: 2/17 assertions failed (19ms) Use --force to continue.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#268 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAVVtZYH0fVbS3kGagE7OFygbAodY_xpks5r1wNAgaJpZM4HQkPq>
.
|
I tear down the grunt-contrib-copy dir and pull everything again, then
|
Then only the OS is left as a variable here. Not sure what else can be done. |
To make sure it's not an artifact of lxc or a side-effect of mixing amd64 host (and kernel) with i386 libc &C, I set up an i386 VirtualBox clone. It is reproducible there too. Should I open an issue on this ? |
If it's something you can consistently reproduce with a clean OS which is the latest stable version, then sure. Weird that Travis CI is passing though. |
done ! travis is running on |
fs.utimesSync
saves times with one second precision, whilefs.statSync
gives us microsecond precision.This makes
utimes
not synchronized on filesystems with sub-secondatime
/ctime
/mtime
precision.Upgraded to use newer
fs.futimesSync
interface providing correct precision.Fixes #257.