cpr icon indicating copy to clipboard operation
cpr copied to clipboard

Intermittent file not done piping

Open kellyselden opened this issue 6 years ago • 4 comments

Given a file named "changed.txt" with the contents:

changed-v1

And with the following code added to the copyFile function:


            fromFile.on('error', onError);
            toFile.on('error', onError);
            fromFile.once('end', function() {
                cb(err);
                if (to === 'changed.txt') {
                  console.error(to);
                  console.error(fs.readFileSync(from, 'utf8'));
                  console.error(fs.readFileSync(to, 'utf8'));
                }
            });
            fromFile.pipe(toFile);

About 50% of the time I get in the console:

changed.txt
changed-v1

changed-v1

And the other 50% I get:

changed.txt
changed-v1


It seems like there may be a race condition in the piping and "end" event. I should also note that there are other files in the operation, and this is the only one affected. For instance using fixturify:

{ 'changed.txt': '',
  'missing-changed.txt': 'changed-v1\n',
  'missing-unchanged.txt': 'unchanged\n',
  'removed-changed.txt': 'changed-v1\n',
  'removed-unchanged.txt': 'unchanged\n',
  'unchanged.txt': 'unchanged\n' }

kellyselden avatar Jul 27 '17 21:07 kellyselden

I'm also using a filter, not sure if that has anything to do with it.

kellyselden avatar Jul 27 '17 21:07 kellyselden

Very conveniently, ncp is a drop-in replacement API. If I replace cpr with ncp, the race condition is gone.

kellyselden avatar Jul 27 '17 22:07 kellyselden

What version of Node are you using? I may have to add a fromFile.once('end' and a toFile.once('end' check to ensure that it's fully copied by the time it moves off to the next. I've seen this come up in other node projects, I just haven't looked at cpr in a while.

davglass avatar Jul 28 '17 12:07 davglass

Ah I can't believe I forgot to tell you node version. I saw this on node 4.8.4 on both my local osx and travis-ci linux. Looking through my appveyor windows logs, looks like it doesn't affect windows. Here is an instance of it failing in the logs https://travis-ci.org/kellyselden/git-diff-apply/builds/258254739#L680-L691.

This first print was after the copy, and the next print was the source.

Another hint: I was having tons of line ending issues cross platform because I'm doing deep file compares with fixture files. I've made progress on my project since the bug yesterday, solving my line ending problem. Now I can't reproduce this issue anymore with my new code. This leads me to believe it may have to do with windows line endings on a unix machine.

kellyselden avatar Jul 28 '17 17:07 kellyselden