Skip to content
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 EEXIST error when building kibana a second time #34852

Merged
merged 9 commits into from
May 1, 2019

Conversation

rudolf
Copy link
Contributor

@rudolf rudolf commented Apr 10, 2019

Summary

Building Kibana for the second time fails with:

│ERROR Error: EEXIST: file already exists, copyfile '/Users/rudolf/dev/kibana/.node_binaries/10.15.2/node.exe' -> '/Users/rudolf/dev/kibana/.node_binaries/10.15.2/windows-x64/node.exe'

This PR unlinks the destination before attempting to do a copy-on-write to prevent these failures.

This PR adds .node_binaries to kbn cleanup and moves the very specialised fs.copy() function into the calling code.

@rudolf rudolf added the Team:Operations Team label for Operations Team label Apr 10, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-operations

@rudolf rudolf added non-issue Indicates to automation that a pull request should not appear in the release notes review v7.2.0 v8.0.0 labels Apr 10, 2019
@elasticmachine
Copy link
Contributor

💔 Build Failed

@jbudz
Copy link
Member

jbudz commented Apr 10, 2019

Test failures look legit :)

@tylersmalley
Copy link
Contributor

Any steps to reproduce? During the build, we remove the entire target/build directories.

@rudolf
Copy link
Contributor Author

rudolf commented Apr 16, 2019

To reproduce:
yarn build && yarn build

The clean task doesn't remove files in .node_binaries/ which is where this problem originates. @tylersmalley would you prefer if we removed that directory too as part of the cleanup task?

@spalger
Copy link
Contributor

spalger commented Apr 16, 2019

I'm kinda suspicious of this, https://nodejs.org/api/fs.html#fs_fs_copyfile_src_dest_flags_callback implies that this is not the behavior of fs.constants.COPYFILE_FICLONE:

  • fs.constants.COPYFILE_EXCL is a thing with the description "The copy operation will fail if dest already exists"
  • Their example is fs.constants.COPYFILE_EXCL | fs.constants.COPYFILE_FICLONE to clone a file exclusively

@rudolf
Copy link
Contributor Author

rudolf commented Apr 17, 2019

@spalger I agree, this is not the behaviour that the documentation suggests, I've created nodejs/node#27273

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

// Delete `destination` since `fs.copyFile` with the copy-on-write reflink/COPYFILE_FICLONE
// flag fails if the destination already exists. https://github.com/nodejs/node/issues/27273
try {
await unlinkAsync(destination);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this still necicary after cleaning the .node_binaries directory? My concern is the overhead of an additional delete call before any copy when it's not needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cleaning node_binaries solves the original problem, so we don't need to add the unlink call.

I kept it there since it felt like a bug in our fs.copy() implementation, because we abstract away how we do the copy, I would expect this to behave like Node's fs.copy and then it weirdly doesn't without it being obvious from the calling code that we're passing in COPYFILE_FICLONE.

Since the whole point of using COPYFILE_FICLONE is for performance it makes sense that we want to prevent unnecessary calls.

I'm thinking perhaps it's best to rename the function to copyOnWrite and add a comment explaining the behaviour, but removing the unlink call.

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💔 Build Failed

@tylersmalley
Copy link
Contributor

Looks like the failure is related

03:25:48   28:3  error  copy not found in './fs'  import/named

@elasticmachine
Copy link
Contributor

💔 Build Failed

@tylersmalley
Copy link
Contributor

retest

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link
Contributor

@tylersmalley tylersmalley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@rudolf rudolf merged commit eb17289 into elastic:master May 1, 2019
@rudolf rudolf deleted the fix-re-build-error branch May 1, 2019 18:14
@rudolf rudolf changed the title Unlink destination before copy-on-write Remove shared fs.copy() function May 1, 2019
rudolf added a commit to rudolf/kibana that referenced this pull request May 1, 2019
* Unlink destination before copy-on-write

* Catch unlink exception if destination file doesn't exist

* Add link to upstream node issue

* Add .node_binaries to kbn cleanup

* Remove unlink call

* Remove fs.copy()

* Fix extract_node_builds_task test

* Remove copy from build/lib exports
@rudolf rudolf changed the title Remove shared fs.copy() function Fix EEXIST error when building kibana a second time May 1, 2019
@elasticmachine
Copy link
Contributor

💔 Build Failed

rudolf added a commit that referenced this pull request May 2, 2019
* Unlink destination before copy-on-write

* Catch unlink exception if destination file doesn't exist

* Add link to upstream node issue

* Add .node_binaries to kbn cleanup

* Remove unlink call

* Remove fs.copy()

* Fix extract_node_builds_task test

* Remove copy from build/lib exports
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
non-issue Indicates to automation that a pull request should not appear in the release notes review Team:Operations Team label for Operations Team v7.2.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants