Meteor 0.9.0.1-rc3 rm_recursive got ENOTEMPTY retrying

[peterennis]

Windows 7 It took 5 minutes to start then reported the error message. Stuck in a look with the same message appearing.

c:\ae>meteor --version
Meteor 0.9.0.1-rc3

c:\ae>meteor create myapp
myapp: created.

To run your new app:
   cd myapp
   meteor

c:\ae>cd myapp

c:\ae\myapp>meteor
[[[[[ c:\ae\myapp ]]]]]

=> Started proxy.
=> Started MongoDB.
rm_recursive got ENOTEMPTY retrying

[peterennis]

meteor list recommends to update, but it does not help. Output message length exceeds standard terminal width.

c:\ae\myapp>meteor list
standard-app-packages  1.0.0* Include a standard set of Meteor packages in yo...

autopublish            1.0.0* Publish the entire database to all clients
insecure               1.0.0* Allow all database writes by default

 * New versions of these packages are available! Run 'meteor update' to update.

c:\ae\myapp>meteor update
Refreshing package metadata. This may take a moment.
This project is already at Meteor 0.9.0.1-rc3, the latest release.

c:\ae\myapp>

[peterennis]

Tried again with setting compatibility option to Windows 7 on meteor.exe Similar result to #60 ... \fibers\future.js:173 throw(ex); I could not capture output as the system went into BSOD mode.

[sdarnell]

Meteor.exe is just a simple .net binary, so setting the compatibility flag on it is unlikely to change behaviour. When this workaround has made a difference for others, they needed to set it on the node.exe binary.

The rm_recursive problem is usually because you have an editor, explorer window, or command prompt open in folder within the build area. Meteor often removes and recreates directories. On Unix this is simple, but on windows you can't delete files that are in use or directories that are not empty. And that's what the message is saying.

Antivirus software also causes the issue, but generally retrying after a delay works. And that's what the windows port does - though it does give up eventually.

The issues with meteor update are common with the Linux version I believe.

[joeapearson]

@sdarnell I've been running into the rm_recursive problem every now and again (Visual Studio is the culprit in my case). It's more of an annoyance than a blocking issue at the moment.

Do you think it'd be worth/possible making Meteor a bit more aware of the fact that another process could be holding onto one of the files? Perhaps some sort of friendly console message to tell the user which process is causing the issue, along with a retry after a few seconds would be helpful? I'd be happy to take a look into this, any pointers?

[sdarnell]

The rm_recursive code already sleeps and retries, and this seems to be enough to get over anti virus, scanners, and windows explorer. But if a file is truly open by another program there's not much we can do.

I could possibly improve the message, but I don't know of a way to determine who has a file open without having elevated privileges. If you know of a way, that would be a good idea.

[peterennis]

Most people that want to build code will be Admins On their box. You could provide more debug messages to The admin account, get better reports And possibly more people to review.

If you add that capability put a note on the Wiki, update this thread and I can provide More detail.

Sent from Yahoo Mail on Android

[joeapearson]

Meteor has a nice feature whereby it doesn't require a privileged location to install and run from. I don't think it'd be good to move away from this on Windows.

@sdarnell I'll look into the latter question of how to work out which process has a file if I get some time (tm). Thanks for your thoughts!

[sdarnell]

@joeapearson I agree. I do not believe that most users will be running elevated (even if they are admins).

This issue also conflates building a release of meteor and running a release of meteor. But the problem is essentially the same. However, one doesn't tend to build releases very often, but having an editor etc. accidentally have a file open or be currently sitting in a directory that needs to be removed, is far more common. And the recipient is less likely to understand.

Currently the error reported could be more specific, and I'll have another look at improving that. Probably having a number of silent retries, before outputting a message and more retries.

Identifying the process that has the for open requires trawling the kernel handle tables. Not something that is viable from node.js. even MS direct people to sysinternals handle/process explorer tools. MSI installer does something as well - but I haven't found any information how it works. But it is clear that the file system itself doesn't store the information with the file.

One other possibility worth trying is to rename directories they can't be deleted. But this may leave trash behind.

[sdarnell]

Aha, I've just found something that might do the trick without elevation. Thanks to Raymond Chen: http://blogs.msdn.com/b/oldnewthing/archive/2012/02/17/10268840.aspx

[sdarnell]

Here's a .net article about the restart manager APIs: http://msdn.microsoft.com/en-us/magazine/cc163450.aspx And some other examples: http://stackoverflow.com/questions/860656/using-c-how-does-one-figure-out-what-process-locked-a-file And http://stackoverflow.com/a/20623302/1129543

Though there is some doubt about whether it handles directories, and there are reports that the API can hang.