The logic to figure out which build dirs are temp dirs which need to be
freed and which are not was wrong, since it missed the non-temp
files.pathResolve(files.pathDirname(packagePath),
packageLinkTarget));
Use a more explicit way of tracking this.
(Fixed merge conflict when merging from devel.)
Summary:
According to its contract, mkdir -p returns true if the directory
exists (and creates it if needed) and false if the item exists and isn't
a directory (so we couldn't make one). Because directory creation can
be concurrent, we need to wrap the actual mkdir call in a try/catch to handle
this issue (rather than just checking once).
This issue was always here. Previously, the race was against other apps editing
the same directory (which didn't come up that often). As of 1.0.3, files.js is a lot
more yieldy and this becomes a race condition on Meteor itself.
Test Plan: self-test
Reviewers: glasser
Differential Revision: https://phabricator.meteor.io/D15
This mostly fixes tests:
- removes the 'restarted' check from some tests. We don't need it in those cases
(printing the other banner is enough). We can no longer rely on that executing
after the code in the package (in fact it seems to execute before, and then
get overwritten), and the test still tests what it is intended to (that the new
package code executes).
- minor fixes to essentially syntax errors -- the skeleton now uses double quotes
instead of single quotes, so a regex failed to work, for example. We changed a
version number in one part of the test, but not another.
- fixes selftest.js, sort of, to actually print out what test we are testing. This
is an unfortunate interaction of Console.js changes in 1.0.2 and a progress bar
(that came later). The progress bar erases the message telling you what test is
running when you use a standard terminal. That's awkward, fixed.
In Session.close, `self.socket.close` could trigger this event handler:
socket.on('close', function () {
if (socket._meteorSession) {
Fiber(function () {
socket._meteorSession.close();
}).run();
}
});
which could trigger a reentrant call to Session.close. The self.inQueue
guard was not sufficient to stop multiple execution, because it was too
low.
Symptoms included:
- The "sessions" server fact would be decremented twice and become
inaccurate (and even negative!)
- Connection.onClose callbacks could be called twice
Fixes#3331.