node-sass: "File to read not found or unreadable" with -w under Windows

  • NPM version (npm -v): 4.2.0
  • Node version (node -v): v7.5.0
  • Node Process (node -p process.versions):
{ http_parser: '2.7.0',
  node: '7.5.0',
  v8: '5.4.500.48',
  uv: '1.10.2',
  zlib: '1.2.8',
  ares: '1.10.1-DEV',
  modules: '51',
  openssl: '1.0.2k',
  icu: '58.2',
  unicode: '9.0',
  cldr: '30.0.3',
  tz: '2016j' }
  • Node Platform (node -p process.platform): win32
  • Node architecture (node -p process.arch): x64
  • node-sass version (node -p "require('node-sass').info"):
node-sass       4.5.0   (Wrapper)       [JavaScript]
libsass         3.5.0.beta.2    (Sass Compiler) [C/C++]
  • npm node-sass versions (npm ls node-sass):
`-- node-sass@4.5.0

Randomly when using node-sass directly from command line (without gulp), it fails with the error:

=> changed: G:\www\styles\styles.scss
{
  "status": 3,
  "message": "File to read not found or unreadable: G:/www/styles/styles.scss",
  "formatted": "Internal Error: File to read not found or unreadable: G:/www/styles/styles.scss\n"
}
=> changed: G:\www\styles\styles.scss
Rendering Complete, saving .css file...
Wrote CSS to G:\www\styles\styles.css
Wrote Source Map to G:\www\styles\styles.css.map

the file exists all the time, the HDD is fine and healthy. it fails around 30% of the time, and I have to re-save the file for the watch to recompile. sometimes it fails 4-5 times in a row. the ownership of the files are fine, no symlinks are being used, if it matters, I’m using VSCode (but the problem happens with EmEditor as well)

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 11
  • Comments: 37 (4 by maintainers)

Most upvoted comments

I’ve created a PR that fix this problem: https://github.com/sass/node-sass/pull/2386

If want to try this fix, you can patch your node-sass local copy by replacing ‘node_modules/node-sass/lib/render.js’ with this version: https://github.com/marcosbozzani/node-sass/blob/bug-vscode-watch/lib/render.js

The diff is here: https://github.com/marcosbozzani/node-sass/commit/266861bf5761dcafd5d53d123264b965c861887c#diff-a485abf5b8f49de7f313d7799df3faf4

I done another test. Now node-sass call is wrapped in setTimeout so it run with some delay, and I’m sure all other operations on this file have ended.

var chokidar = require('chokidar')
var fs = require('fs')
var path = require('path')
var sass = require('node-sass')

var srcDir = path.resolve(__dirname, "../src")
var distDir = path.resolve(__dirname, "../dist")

chokidar.watch(path.join(srcDir, "**/*.scss")).on('all', (event, _path) => {
    console.log("File changed: ", _path)
    setTimeout(() => {
        sass.render(
            {
                file: path.join(srcDir, "styles/main.scss"),
                outFile: path.join(distDir, "main.css"),
                sourceMap: true
            },
            function (err, result) {
                if (err) {
                    console.log(err)
                } else {
                    fs.writeFile(path.join(distDir, "main.css"), result.css, (err) => {
                        if (err) {
                            console.log(err)
                        }
                    })
                    fs.writeFile(path.join(distDir, "main.css.map"), result.map, (err) => {
                        if (err) {
                            console.log(err)
                        }
                    })
                }
            }
        )
    }, 100)
})

Result: no errors 😄

Now I’m sure it’s as I described in the previous comments

Actually I didn’t solve this problem but I found a way to make it not interfere.In VS code you can simply replace a black space with a blank space using “ctrl+h” or by going to “edit” or manually and save the file then this problem doesn’t appear.

2 1

works win10 node-sass 4.9.2 thx @marcosbozzani

@marcosbozzani works form me on windows 10 and node-sass 4.9.0 version! Thanks a lot!

@sbfkcel this situation can occur because the VS Code and Node.js processes operate independently of each other. The problem lies with the lib-sass side, that does not check whether the file is currently readable.

In other transplers like LESS or Stylus, this problem probably is not occur (I haven’t analyzed their code) because they are much slower and before they start reading from the file, the IDE is able to perform all operations on the file. Or they simply wait befere file is readable, but as I says, I didn’t analyze their code.

This sounds like an issue with atomic saves. Make sure you disable atomic_save in Sublime.