-
Notifications
You must be signed in to change notification settings - Fork 774
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
v8 release #667
v8 release #667
Conversation
I will rebase this! |
@manidlou Thanks for your changes. Recommended default values: {
"overwrite": false,
"checkPathsBeforeCopying": false
} |
@manidlou Looks like somehow you managed to duplicate most of the commits in this branch. Please fix. |
@RyanZim yeah i know! I will fix it for sure! |
* copy*(): fix copying bind-mounted dirs * copy*(): fix case-insensitive-paths tests * copy*(): refactor to check paths more efficiently * destructure stats object after checking err
fixed the commits! |
Hi, |
This issue does not fix the issue directly. It's a option to disable the checkPaths-method. This is more a workaround. The Inode-Issue still exists with the option enabled. I think that was not quite understood. But please correct me if I am wrong. 🙂 This finally means, Cordova has to update |
How is this coming along? Cordova will need to make a new release with your version 8 to fix major issues in windows build servers. |
It's a very ugly issue, and because it hasn't been solved for so long, i think this project is not a reliable solution. Can the Cordova project team consider alternative solutions to node-fs-extra |
Sorry for the long wait. I've been very busy, plus suffering from a bit of burnout. |
@manidlou Do you want me to help with releasing v8, or do you want to do it yourself? I'm good with it either way. |
@RyanZim I dream of a vast green landscape where I spend my remaining life. No stress. No technology. Just sit by a lake and look up at the sky and sleep under the stars. You too? #burnout 😄 Shape the world. |
@Domvel we are very well aware of the issue. As I mentioned in the description, we use Honestly I've been thinking about this a lot for awhile and I personally like to fix this right and the only reason that I went down the road of adding the So @jprichardson @RyanZim @JPeer264 although I myself worked on this workaround, this is how I suggest to handle this:
Also @Domvel |
Alright it should be ready now! updated the description as well! Once it is approved, @RyanZim will you please take care of the changelog and I will do the rest of it? 😃 |
@jprichardson @RyanZim @JPeer264 please let me know if you have any concerns about this 😃 |
@RyanZim best wishes and hope you will get better :) I'm okay with those changes. It's good that you marked the |
Items from this PR that should be in the release notes:
@manidlou Did I miss anything? We should also drop Node 6. No need to make code changes for it, just drop it in the release notes. |
If you drop node 6 Cordova will not be able to use your new version to fix
the bug as that would be a breaking change. You have to support node 6
Please read this:
https://github.com/apache/cordova-common/issues/64#issuecomment-490502763
|
I would favor a statement that Node.js version 6 is deprecated and will be dropped in the near future. I would also favor a similar statement for Node.js version 8, considering that its EOL is coming up in December. As @dimitriscsd said, Cordova still needs to support Node.js 6 until we make another major release. |
Let's put out a statement that we'll drop Node v6 in the future as it's deprecated. I think this version of |
@RyanZim the items from this PR for release notes are correct. Thanks for taking care of that! Also i just saw your comment in the pile of comments! Hope you feel better! |
@manidlou I went ahead and published v8.0.0. |
@RyanZim you did the right thing! Thanks for taking care of that! |
Sorry, a bit late to the party... Does this mean that on node < 10.5, there is still a random chance of failure due to the bigint inode problem? In other words, that this is fixed only for node 10.5 and above? (That's both what I understand from the source code, and what I seemed to have experienced myself.) |
Note: I understand there's no magical solution here and we just can't use 'bigint' with fs in Node < 10.5, but I was wondering whether there could be tighter heuristics for the legacy case. I initially thought the suggestion from #657 (comment) could have merit, but I think it wouldn't work with hardlinks and would leak to corrupted files. Instead, relying also on other file stats could help detect different files with incorrectly identical inode values (due to the Number representation). E.g. in legacy form, if the inodes match, but either one of the timestamps or the size don't, then allow the copy because we know it's not the same file, otherwise reject it because it may be the same file. I could open a PR for that. |
@jprichardson Sure. Though my problem isn't with the fact that |
We can move that conversation there, it would make much more sense than here on the v8.0.0 release PR :) |
I think it is time to release v8. @jprichardson @RyanZim @JPeer264 please let me know if you think differently!
graceful-fs
has not been updated yet to supportbigint
option. I opened an issue there, but they haven't been updated their code yet! So, switched to built-infs
forcopy*()
andmove*()
for now, so that we can usebigint
option. We will switch back tograceful-fs
once the upstream is updatedstandard-markdown
as it started giving us more headaches than benefits!copy*()
fs.stat()
withbigint
option for node versions that support it>= 10.5.0
and use oldfs.stat()
withoutbigint
for older node versions.Source and destination must not be the same
error if src and dest have the same ino and exist on the same device.move*()
stat
functions.Fixes #608, #613, #614, #657.