This was dangerous because source is often a path relative to the old
target file, whereas files.stat was interpreting source as a path relative
to process.cwd().
Fixes#9203.
A while back, for performance reasons, we disabled yielding for all
files.* operations unless METEOR_DISABLE_FS_FIBERS was set to false.
This was safe for almost all files.* operations, because most of them have
a synchronous fs.*Sync version available.
For a more complicated operation like files.rm_recursive, however, there
is no synchronous or asynchronous counterpart in the fs.* namespace, so
the safety of disabling fibers is not guaranteed.
Lately, files.rm_recursive has become a major source of uncaught ENOTEMPTY
errors on Windows, because rimraf.sync fails with that error, and we don't
give files.rm_recursive_async a chance to delete the directory in a more
persistent, forgiving manner.
The only reason we haven't been falling back to files.rm_recursive_async
is that YIELD_ALLOWED is false by default, so canYield() returns false.
This commit distinguishes between canYield() and mayYield(), and uses
canYield() in files.rm_recursive to determine whether it is technically
safe to yield, regardless of YIELD_ALLOWED.
Anyone who ever asked "Can I go to the bathroom?" in elementary school,
only to be mercilessly rebuked with "I don't know, CAN YOU?" should
understand the difference between these two functions.
These errors are especially harmful because they cause files.rename to
fall back to copying rather than atomically renaming, which is both much
slower and not even remotely atomic.
This reverts commit b9f0a54b39.
Though probably a good idea for the future, this change was not really
necessary for Meteor 1.6, and probably too risky for a release candidate.
The `installPath` property was always essentially an absolute module
identifier that was simply missing the leading '/' character, so this
commit acknowledges that role by renaming the property to `absModuleId`
and adding the leading slash.
Previously, if more than one module in a package tried and failed to
import the same identifier, we would record information about only the
last failed import.
This was good enough for later attempting to resolve the failed import in
other packges or the application's `node_modules` directory (a concept
known as "peer dependencies"), but it sometimes discarded information
about whether the failed imports were dynamic. In particular, if the last
recorded failed import was a dynamic import, it could accidentally render
the entire peer dependency tree dynamic.
Although it's a bit more complicated than what we did before, I believe
the simplest solution is for the ImportScanner to maintain a mapping from
failed identifiers to lists of import information objects, rather than a
single object, so that no information is lost.
While the actual version included for Unix developers will be our own
build at NODE_VERSION, this is important for the Windows version, since
it is not being rebuilt by our Jenkins at the moment.
Thanks to changes in the `build-node-for-dev-bundle.sh` script done in
0583e5883c, we now build a tarball which
is identical to the structure provided by Node.js themselves.
While generally we are using the main Node releases, this will allow
our users to (if need be), use a tarball directly in place of their own
in production without additional changes. Similarly, the only change
we need to make now when building the dev bundle is to use a different
URL.
The changes added in
d854a4b9ba
fixed a long standing issue where the Accounts system was
overwriting other DDP `connection.onReconnect` callbacks,
that were potentially set by developers (and vice-versa -
developers could overwrite the `onReconnect` callback registered
by the Accounts system, which impacted logging back in after
reconnecting). Unfortunately these changes are also registering a
new duplicate `onReconnect` callback to be called, after every
login. These duplicate callbacks pile up and are all called when
reconnecting, which eventually breaks user logins.
The changes in this commit make sure that any previously set
Accounts login `onReconnect` callback is first removed, before
adding a new callback. This ensures the Accounts system is only
ever setting one `onReconnect` callback after logging in.
Fixes#9140.
