Conversation
| fs.stat(from, function (fromStater, fromSt) { | ||
| if (!fromSt && toSt) { | ||
| if (cb) cb(toStater ? er : null) | ||
| } else if (fromSt && toSt && fromSt.size === toSt.size) { |
There was a problem hiding this comment.
Not really fond about this, so could use some feedback/input on how it could be solved differently.
| throw e | ||
| } | ||
| // Wait until destination exists and source no longer exists or that we've reached the backoff limit | ||
| while ((fs.existsSync(from) || !fs.existsSync(to)) && Date.now() < backoffUntil) {} |
There was a problem hiding this comment.
Possibly the worst hack ever, but it seems to be the only real way to solve inconsistent behavior on Windows where the destination and source can exist at the same time.
|
testing this out on a windows machine lead to crash: "error": "TypeError: Cannot read property 'size' of undefined", "errorStackTrace": "TypeError: Cannot read property 'size' of undefined\n at node_modules\graceful-fs\polyfills.js:112:45\n at node_modules\graceful-fs\polyfills.js:331:29\n at FSReqWrap.oncomplete (fs.js:114:15)" taking a quick look -- perhaps there needs to be error handling on the first call to fs.stat? Node v7.9.0 |
|
@conceptualspace I've added some additional sanity checks that should solve your crash. Thanks for testing and reporting the issue! |
|
Thanks @mekwall for writing this patch! I work on TypeScript, Visual Studio, and Visual Studio Code. The underlying problem described here is coming up a lot for VS developers because the TypeScript language service puts a file watcher on the project folder (including when the user is just writing JavaScript). We typically see errors like this: As the PR describes, this is definitely related to file watchers - in my testing, if we disable the file watching from the TSLS side, the error stops happening. I've done some testing and this PR definitely fixes the issue. The particular scenario we're trying to make work has gone from failing 1 in 4 times to succeeding the last 35 times in a row. We really need this to be merged - it's impacting a lot of developers and there's nothing that can be done on our end. Developers running |
|
Thank you, thank you, thank you, thank you, thank yo----- It may take longer to run a big |
|
NPM team really needs to merge this PR ASAP, could any guys in their team give a response? |
|
Hi. It seems like there's a semantic change here. If the target directory is not empty, then it should fail with Also, I'm not sure it's a good idea to spin on CPU for potentially 60 seconds in this case. Is it possible to make this time shorter, or allow it to be configured? |
|
Sadly I don't have time to fix this at the moment. Any takers? |
|
Closing this in favor of #131. |
Summary
This PR improves on the existing override for
fs.renameand also adds a similar but blocking override forfs.renameSync(obsoleting #23). The overrides tries to normalize the behavior offs.renameandfs.renameSyncbetween platforms. It does this by ensuring that the file was actually moved before resolving within a 60 second time frame.Background
fs.renameandfs.renameSyncuses MoveFileEx function on Windows. It is not an atomic operation and honors the Windows sharing modes, meaning that whenever a file or parent directory is locked (in use) the rename might fail with EACCS or EPERM errors depending on the sharing mode set on the file and/or directory.This differs from how the api call used by Linux and OSX works where the rename operation is atomic and will go through no matter if the file is locked or not.
Disabling anti-virus is NOT a viable solution
Most active anti-virus file scanners will lock the file and/or directory during scan, so if you are trying to rename it during this time you'll get an EPERM/EACCS error thrown in your face. Just to be clear: Disabling AV is NOT a viable solution and should never be accepted as such.
Issues possibly affected by this
npm install purecssFails on windows 10 pure-css/pure#647References