Open kellyselden opened 7 years ago
I'm also using a filter, not sure if that has anything to do with it.
Very conveniently, ncp is a drop-in replacement API. If I replace cpr
with ncp
, the race condition is gone.
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.
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.
Given a file named "changed.txt" with the contents:
And with the following code added to the
copyFile
function:About 50% of the time I get in the console:
And the other 50% I get:
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: