ENOTEMPTY Error Running App on Windows 10

help
1

I am trying to set up a dev environment on Windows 10 for an app I built on Mac - it’s package based upgraded to 1.4.4.1

I have 1.4.4.1 running on windows 10.

I created an empty meteor app then copied my source to it.

I then ran meteor npm update

I then ran meteor npm rebuild

I have re-installed meteor

I was going through my source making sure the file names of what I am referencing in my package.js files are the same names and case as they are named on disk - this seemed to be helping me with some ENOTEMPTY errors but now no matter what I do I get the following error. Note that the directory it is pointing to is in fact EMPTY.

So I am having a hard time debugging this error. If anyone has any ideas for stuff I can try to get past this on windows 10 that would be freakin’ awsome.

Note my code base is a mixture of modules and the legacy global references - in the process of converting as I touch stuff.

Thanks in advance.

C:\Users\drollins\AppData\Local\.meteor\packages\templating-compiler\1.3.2\plugin.compileTemplatesBatch.os\npm\node_modules\meteor\promise\
node_modules\meteor-promise\promise_server.js:190
      throw error;
      ^

Error: ENOTEMPTY: directory not empty, rmdir 'C:\Code\Meteor\test\.meteor\local\isopacks\.build856533.tiu-brackets\web.browser\client'
    at Error (native)
    at Object.fs.rmdirSync (fs.js:758:18)
    at rmkidsSync (C:\Users\drollins\AppData\Local\.meteor\packages\meteor-tool\1.4.4_1\mt-os.windows.x86_32\dev_bundle\lib\node_modules\ri
mraf\rimraf.js:332:11)
    at rmdirSync (C:\Users\drollins\AppData\Local\.meteor\packages\meteor-tool\1.4.4_1\mt-os.windows.x86_32\dev_bundle\lib\node_modules\rim
raf\rimraf.js:322:7)
    at rimrafSync (C:\Users\drollins\AppData\Local\.meteor\packages\meteor-tool\1.4.4_1\mt-os.windows.x86_32\dev_bundle\lib\node_modules\ri
mraf\rimraf.js:293:9)
    at C:\Users\drollins\AppData\Local\.meteor\packages\meteor-tool\1.4.4_1\mt-os.windows.x86_32\dev_bundle\lib\node_modules\rimraf\rimraf.
js:330:5
    at Array.forEach (native)
    at rmkidsSync (C:\Users\drollins\AppData\Local\.meteor\packages\meteor-tool\1.4.4_1\mt-os.windows.x86_32\dev_bundle\lib\node_modules\ri
mraf\rimraf.js:329:26)
    at rmdirSync (C:\Users\drollins\AppData\Local\.meteor\packages\meteor-tool\1.4.4_1\mt-os.windows.x86_32\dev_bundle\lib\node_modules\rim
raf\rimraf.js:322:7)
    at rimrafSync (C:\Users\drollins\AppData\Local\.meteor\packages\meteor-tool\1.4.4_1\mt-os.windows.x86_32\dev_bundle\lib\node_modules\ri
mraf\rimraf.js:293:9)
    at C:\Users\drollins\AppData\Local\.meteor\packages\meteor-tool\1.4.4_1\mt-os.windows.x86_32\dev_bundle\lib\node_modules\rimraf\rimraf.
js:330:5
    at Array.forEach (native)
    at rmkidsSync (C:\Users\drollins\AppData\Local\.meteor\packages\meteor-tool\1.4.4_1\mt-os.windows.x86_32\dev_bundle\lib\node_modules\ri
mraf\rimraf.js:329:26)
    at rmdirSync (C:\Users\drollins\AppData\Local\.meteor\packages\meteor-tool\1.4.4_1\mt-os.windows.x86_32\dev_bundle\lib\node_modules\rim
raf\rimraf.js:322:7)
    at Function.rimrafSync [as sync] (C:\Users\drollins\AppData\Local\.meteor\packages\meteor-tool\1.4.4_1\mt-os.windows.x86_32\dev_bundle\
lib\node_modules\rimraf\rimraf.js:293:9)
    at Object.rm_recursive (C:\tools\fs\files.js:303:12)
    at Builder.abort (C:\tools\isobuild\builder.js:696:11)
    at [object Object].saveToPath (C:\tools\isobuild\isopack.js:1681:15)
    at C:\tools\isobuild\isopack-cache.js:380:23
	   at IsopackCache._ensurePackageLoaded (C:\tools\isobuild\isopack-cache.js:241:20)
    at C:\tools\isobuild\isopack-cache.js:77:14
    at C:\tools\packaging\package-map.js:57:7
    at Function._.each._.forEach (C:\Users\drollins\AppData\Local\.meteor\packages\meteor-tool\1.4.4_1\mt-os.windows.x86_32\dev_bundle\lib\
node_modules\underscore\underscore.js:87:22)
    at [object Object]._.extend.eachPackage (C:\tools\packaging\package-map.js:49:7)
    at IsopackCache.buildLocalPackages (C:\tools\isobuild\isopack-cache.js:76:24)
    at C:\tools\project-context.js:841:25
    at C:\tools\utils\buildmessage.js:359:18
    at [object Object]._.extend.withValue (C:\tools\utils\fiber-helpers.js:89:14)
    at C:\tools\utils\buildmessage.js:352:34
    at [object Object]._.extend.withValue (C:\tools\utils\fiber-helpers.js:89:14)
    at C:\tools\utils\buildmessage.js:350:23
    at [object Object]._.extend.withValue (C:\tools\utils\fiber-helpers.js:89:14)
    at Object.enterJob (C:\tools\utils\buildmessage.js:324:26)
    at ProjectContext._buildLocalPackages (C:\tools\project-context.js:840:18)
    at C:\tools\project-context.js:283:9
    at C:\tools\utils\buildmessage.js:359:18
    at [object Object]._.extend.withValue (C:\tools\utils\fiber-helpers.js:89:14)
    at C:\tools\utils\buildmessage.js:352:34
    at [object Object]._.extend.withValue (C:\tools\utils\fiber-helpers.js:89:14)
    at C:\tools\utils\buildmessage.js:350:23
    at [object Object]._.extend.withValue (C:\tools\utils\fiber-helpers.js:89:14)
    at Object.enterJob (C:\tools\utils\buildmessage.js:324:26)
    at ProjectContext._.extend._completeStagesThrough (C:\tools\project-context.js:273:18)
    at C:\tools\project-context.js:265:12
    at Function.run (C:\tools\tool-env\profile.js:490:12)
    at ProjectContext._.extend.prepareProjectForBuild (C:\tools\project-context.js:264:13)
    at C:\tools\runners\run-app.js:563:29
    at C:\tools\utils\buildmessage.js:271:13
    at [object Object]._.extend.withValue (C:\tools\utils\fiber-helpers.js:89:14)
    at C:\tools\utils\buildmessage.js:264:29
    at [object Object]._.extend.withValue (C:\tools\utils\fiber-helpers.js:89:14)
    at C:\tools\utils\buildmessage.js:262:18
    at [object Object]._.extend.withValue (C:\tools\utils\fiber-helpers.js:89:14)
    at C:\tools\utils\buildmessage.js:253:23
    at [object Object]._.extend.withValue (C:\tools\utils\fiber-helpers.js:89:14)
    at Object.capture (C:\tools\utils\buildmessage.js:252:19)
    at bundleApp (C:\tools\runners\run-app.js:562:31)
    at [object Object]._.extend._runOnce (C:\tools\runners\run-app.js:631:35)
    at [object Object]._.extend._fiber (C:\tools\runners\run-app.js:890:28)
    at C:\tools\runners\run-app.js:417:12
1 Like
2

have u installed babel-runtime like meteor npm install --save babel-rc

3

I installed the babelruntime but it did not solve my problem.

I began digging around some more and looked more closely at rimraf.js. The library has a more recent version than the one that is packed with Meteor installer for Windows - it has some windows processing improvements - I swapped that in but the problem still persists.

Then I began looking at what things look like right before the failure and I am finding that there is indeed a temp file in the directory which is no longer there by the time the build stops so it looks like this ENOTEMPTY error was thrown for no reason.

I am now looking earlier in the process in Meteor code to see if there is a better place to tell rimraf to do it’s thing, a time after all temp files are closed.

I am pretty sure this is a sequence of events thing.

Stay tuned more to come.

4

OK so I figured out my issue.

It was indeed that the file names on disk did not match (case sensitive) the file names referenced in my package.js file.

I think it was working on my Mac because I had not changed any of these files for a while now and the compile only looks at changed files normally.

When I ported to windows of course all files were built “compiled” that first time - and this error cropped up.

So this is not a bad thing per se but the error message completely sucks. I mean - it is a bit obtuse. If it’s important that the file names be matched case sensitively then there should be a check for this in the compile process that calls this out to let the developer they are doing something stupid.

There’s a an open PR #8614 where I will reference this post.

5

I deleted all content in /Users/myComp/AppData/local/Temp.
and also deleted all folders under myProject/.meteor/local/ that has build-garbage in their name.

and now the issue is solved.

If someone need help with deleting files with long names from the Temp folder here is a good explenation: windows - delete files with long names

1 Like
6

General fix for the ENOTEMPTY error under Windows:

7

Unfortunately this general fix and other tips doesn’t help with a new installation under Windows.

Like the OP I’m trying to build my app under Windows when it does build successful under MacOS without problems.

I’m getting problems with the same package it seems:

DEBUG  electronApp:  deleting source files
Error: ENOTEMPTY: directory not empty, rmdir 'C:\Users\Administrator\frontend\.meteor\desktop-build\app'
    at Object.rmdirSync (node:fs:1180:10)
    at rmkidsSync (C:\Users\Administrator\frontend\node_modules\del\node_modules\rimraf\rimraf.js:364:25)
    at rmdirSync (C:\Users\Administrator\frontend\node_modules\del\node_modules\rimraf\rimraf.js:342:7)
    at Function.rimrafSync [as sync] (C:\Users\Administrator\frontend\node_modules\del\node_modules\rimraf\rimraf.js:312:9)
    at C:\Users\Administrator\frontend\node_modules\del\index.js:68:11
    at Array.map (<anonymous>)
    at Function.sync (C:\Users\Administrator\frontend\node_modules\del\index.js:60:37)
    at C:\Users\Administrator\frontend\node_modules\@meteor-community\meteor-desktop\lib\electronApp.js:112:25
    at C:\Users\Administrator\frontend\node_modules\asar\lib\asar.js:155:18
    at writeFileListToStream (C:\Users\Administrator\frontend\node_modules\asar\lib\disk.js:42:10)
    at ReadStream.<anonymous> (C:\Users\Administrator\frontend\node_modules\asar\lib\disk.js:37:16)
    at ReadStream.emit (node:events:539:35)
    at endReadableNT (node:internal/streams/readable:1345:12)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)

Tried the whole day and I’m running out options. Please note that the project is running under Meteor version 2.5.6 due to the breaking changes in version 2.6 and onwards.

Any help is highly appreciated

8

Are you using the same Node and NPM version as the MacOS?
Try running NODE_TLS_REJECT_UNAUTHORIZED=0 before Meteor

9

No, it took me several hours to fix that as Windows is the worst OS to run nodeJS on. Now both are on node v14.19.1

What does this do and to confirm I should run it before installing Meteor? Or before trying to build the Windows version of our app with Meteor-Desktop?

NODE_TLS_REJECT_UNAUTHORIZED=0
'NODE_TLS_REJECT_UNAUTHORIZED' is not recognized as an internal or external command,
operable program or batch file.
10

Yeah, Windows is the worst OS to run Nodejs applications, I would use Windows with WSL, way easier to install everything and it works like in an Ubuntu environment.
I’ll ask a teammate to test on Windows 10. I’m on m1, so I can not reproduce your issue

Check the documentation about this command: NODE_TLS_REJECT_UNAUTHORIZED=0

1 Like
11

I have never heard about WSL (I’m a Mac user like you for the last 15 years or so). Will the Meteor-Desktop still build for Windows if Node (and Meteor?) is then running in that Linux subsystem?

I’m already running Win10 in a VM on my Synology server, so it’s far from optimal but I only need that setup/environment to build the Windows version of our app as unfortunately most users are still on Microsoft :frowning:

12

isn’t it possible to build from Mac or Linux just passing --win flag?

13

I haven’t tried it but it’s only possible if there’s no native dependency (see Multi Platform Build - electron-builder). But it’s worth a try, thanks for your help and recommendations.