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

Error: ENOTEMPTY, directory not empty when running npm test #235

Closed
alanning opened this issue Jan 17, 2014 · 4 comments
Closed

Error: ENOTEMPTY, directory not empty when running npm test #235

alanning opened this issue Jan 17, 2014 · 4 comments

Comments

@alanning
Copy link
Contributor

I get the following error when running tests on a new VM with clean clone of Meteorite:

  invoking `mrt run`
    in a non-meteor project directory
      ✓ should display a message about not being in a meteor project dir (327ms)
    in a meteor project without a smart.json
      ✓ should run the app without installing anything (4000ms)
    in a meteor project with a smart.json
      and the smart.json specifies a simple smart package dependency
        ✓ should install the smart package (4515ms)
      and the smart.json specifies a smart package pinned to a branch
        ✓ should install the smart package pinned to a specified branch (4518ms)
      and the smart.json specifies a smart package repo pinned to a tag
        1) "before each" hook


  116 passing (40s)
  1 failing

  1)  "before each" hook:
     Error: ENOTEMPTY, directory not empty '/Users/alanning/src/js/meteorite/spec/var/home/app-with-smart-pkg-pinned-to-branch/.meteor/local'
      at Object.fs.rmdirSync (fs.js:612:18)
      at Object.exports.rmdirSyncRecursive (/Users/alanning/src/js/meteorite/node_modules/wrench/lib/wrench.js:157:15)
      at Object.exports.rmdirSyncRecursive (/Users/alanning/src/js/meteorite/node_modules/wrench/lib/wrench.js:146:21)
      at Object.exports.rmdirSyncRecursive (/Users/alanning/src/js/meteorite/node_modules/wrench/lib/wrench.js:146:21)
      at Object.exports.rmdirSyncRecursive (/Users/alanning/src/js/meteorite/node_modules/wrench/lib/wrench.js:146:21)
      at Context.<anonymous> (/Users/alanning/src/js/meteorite/spec/acceptance/test_spec.js:45:12)
      at Hook.Runnable.run (/Users/alanning/src/js/meteorite/node_modules/mocha/lib/runnable.js:221:32)
      at next (/Users/alanning/src/js/meteorite/node_modules/mocha/lib/runner.js:263:10)
      at Object._onImmediate (/Users/alanning/src/js/meteorite/node_modules/mocha/lib/runner.js:280:5)
      at processImmediate [as _immediateCallback] (timers.js:330:15)
@alanning
Copy link
Contributor Author

This is caused by a change in behavior by the wrench package. In wrench 1.5 the default behavior changed to not delete a directory if its not empty.

Can see this in action by manually setting the wrench version between 1.5.4 and 1.3.9 in Meteorite's package.json file.

Reverting to wrench 1.3.9 fixes the issue. PR coming soon.

@alanning
Copy link
Contributor Author

FYI, opened a ticket on wrench repo since there is no way to override the behavior in latest wrench: ryanmcgrath/wrench-js#71

@alanning
Copy link
Contributor Author

I'm still seeing this every once in a while. Since its an intermittent issue, i'd say its a timing thing.

I tried replacing wrench with rifraf, another rm -f implementation and I still saw the error.

So that leads me to believe it is because some part of the meteor process (or mongo) has not finished yet and still has open files in the .meteor/local folder so that is causing the rm -fto fail.

I don't see the error anymore if I make the test_spec.js script retry the deletion a few times. Its nasty but it seems to work.

What do you think?

@tmeasday
Copy link
Member

We should be killing the meteor process properly but maybe we aren't quite getting it.

I'm not too stressed if the tests are hacky as long as they usually work and actually test what they are supposed to :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants