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

pocesar commented 7 years ago

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)

tuanngominh commented 7 years ago

I face the same issue with v4.5.0 on Windows 10. node-sass watch compiles for the first change then show error for the second change.

The same node-sass version run well on Mac OSX 10.11.6

mikejav commented 7 years ago

I also have this issue on Windows 10 and node v6.9.5 when calling from node script

...
function style() {
        sass.render({
            file: path.join(path_style, 'main.sass')
        }, function (err, result) {
            if (err)
                console.log(err);
            else
                fs.writeFileSync(
                    path.join(path_dist, `style.css`),
                    result.css
                );
        });
}

var style_watcher = chokidar.watch([
    path.join(path_style, '/**/*.sass')
]);
style_watcher.on('change', style);
style_watcher.on('unlink', style);

In ./src/style:

when create new file _Foo.sass- OK
when add @import Foo to main.sass and save- ALWAYS ERROR (shown below)
when save again- OK

{ Error: File to read not found or unreadable: C:/Users/MJ420/Desktop/sass_test_project/src/style/main.sass
    at Object.module.exports.renderSync (C:\Users\MJ420\Desktop\sass_test_project\node_modules\node-sass\lib\index.js:439:16)
    at FSWatcher.style (C:\Users\MJ420\Desktop\sass_test_project\tools\tasks\main.js:158:27)
    at emitTwo (events.js:106:13)
    at FSWatcher.emit (events.js:191:7)
    at FSWatcher.<anonymous> (C:\Users\MJ420\Desktop\sass_test_project\node_modules\chokidar\index.js:191:15)
    at FSWatcher._emit (C:\Users\MJ420\Desktop\sass_test_project\node_modules\chokidar\index.js:233:5)
    at FSWatcher.<anonymous> (C:\Users\MJ420\Desktop\sass_test_project\node_modules\chokidar\lib\nodefs-handler.js:263:16)
    at FSReqWrap.oncomplete (fs.js:123:15)
  status: 3,
  message: 'File to read not found or unreadable: C:/Users/MJ420/Desktop/sass_test_project/src/style/main.sass',
  formatted: 'Internal Error: File to read not found or unreadable: C:/Users/MJ420/Desktop/sass_test_project/src/style/main.sass\n' }

VladSenko commented 7 years ago

Have the same error when making the following steps:

Run node-sass with -w option.
Create the new directory inside the watched directory.
Create and save *.scss file inside the new directory.

ERROR:

{
    "status": 3,
    "message": "File to read not found or unreadable: F:/Rabbit/Site/src/app/assets/scss/test3",
    "formatted": "Internal Error: File to read not found or unreadable: F:/Rabbit/Site/src/app/assets/scss/test3\n"
}

OS: Windows 10 Editor: Visual Studio Code NPM: v. 3.10.10 NODE: v. 6.10.0

snaumov commented 7 years ago

Same issue on win10, node 7.7.4, visual studio code 1.10.2 It seems as if node-sass attempts to access the .sass file at the very moment it's locked by ide or something like that. So it happens no every time (1/3 of saves) and usually works on second save.

iuriidanylevych commented 7 years ago

Same issue on win10, node 6.9.5 when using node-sass with --watch flag. Passed it using nodemon: "build-css": "node-sass src/ -o src/", "watch-css": "nodemon -e scss -x \"npm run build-css\""

AlexStek commented 7 years ago

Hi, I've the same error when run such npm script:

"scripts": {
    "css:build": "node-sass src/scss/main.scss -o dist/css/ --output-style compressed",
    "css:watch": "npm run css:build && npm run css:build -- -w",
    "css": "npm run css:watch"
  },

I'm using VS Code. After I tried to edit and save sccs file with notepad there are no any issues, all works fine. Who have troubles do you all also use VS Code?

OrionPro commented 7 years ago

Have the same error when making the following steps... { "status": 3, "message": "File to read not found or unreadable: d:/work/project_react/src/App.sass", "formatted": "Internal Error: File to read not found or unreadable: d:/work/project_react/src/App.sass\n" } "devDependencies": { "node-sass": "^4.5.2", "npm-run-all": "^4.0.2", "react-scripts": "0.9.5" }, "scripts": { "build-css": "node-sass src/ -o src/", "watch-css": "npm run build-css && node-sass src/ -o src/ --watch --recursive", "start-js": "react-scripts start", "start": "npm-run-all -p watch-css start-js", "build": "npm run build-css && react-scripts build", "test": "react-scripts test --env=jsdom", "eject": "react-scripts eject" }

OS: Windows 10 Editor: sublime text NODE: v4.4.7

xzyfer commented 7 years ago

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

xzyfer commented 7 years ago

You're also likely to have issues if you files are on a networked drive or container because of delays when writing the files.

This is a limitation of filesystem watchers and not something node-sass can do anything about.

pocesar commented 7 years ago

grunt-watch works flawlessly, so it is a problem with node-sass

morhaham commented 7 years ago

Have the same problem.

saper commented 7 years ago

Could all the "me too" people say clearly which filesystem are they using on the affected drive?

Is it local NTFS drive? SMB share? Something virtualized?

If this is not a local NTFS drive? Can you reproduce the problem using local C: drive?

pocesar commented 7 years ago

NTFS, local, primary

morhaham commented 7 years ago

NTFS, local, secondary. I have to save the scss file twice, and then it will update my css file. This error occurs every time I save but only at the first save.

umkasanki commented 7 years ago

try https://www.npmjs.com/package/gulp-wait

saper commented 7 years ago

I am afraid this must be something with the way node watches file changes, not much we can do with node-sass :( it probably belongs to the node itself

mikejav commented 7 years ago

I decided to take a closer look at this problem. I used Process Monitor to analyze what exactly happens after saving the file I mentioned earlier. Here are the results when error: filtered-error

It seems that when a file is saved, sometimes VS Code does not keep up closing the file, while chokidar already triggered node-sass's job.

And this is a capture log when the file is processed without errors: filtered-legit

In both cases, only files from src and dist directories were captured.

Watcher code used for test::

// filename: development.js
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)
    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 {
                console.log(result)
                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)
                    }
                })
            }
        }
    )
})

mikejav commented 7 years ago

I'm not familiar with c++ but it seems like this line is suspicious: 554: char* contents = read_file(abs_path); I have not found function's read_file documentation, but it seems when read locked file this return empty string. IMO better idea is wait (with timeout) until file is unlocked and then read file.

mikejav commented 7 years ago

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 :D

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

mikejav commented 7 years ago

@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.

sbfkcel commented 6 years ago

@mikejav I think it should be like this. My solution now is to pass string-wise to node-sass to ensure the file is valid.

But there is still a problem, node-sass for some special character support may not be very friendly.

https://github.com/sass/node-sass/issues/2171

Kailash-yadav commented 6 years ago

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.

marcosbozzani commented 6 years ago

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

MatteoPieroni commented 6 years ago

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

ihd2911 commented 6 years ago

"node-sass": "^4.9.0", didn't worked for me, had to replace the file, only then it worked @MatteoPieroni @marcosbozzani

Timikcool commented 6 years ago

@marcosbozzani it worked! thx so much

hrodberaht commented 6 years ago

works win10 node-sass 4.9.2 thx @marcosbozzani

eriksonoliveira commented 6 years ago

Thanks a lot!

drizzyemtk54 commented 6 years ago

thanks mate @marcosbozzani ..it really works!

rmnrdi commented 6 years ago

I'm using version 5.6.0 (npm - v sass) and it breaks sass. Am I doing something wrong?

BramVanroy commented 6 years ago

@marcosbozzani Thanks for the PR but this doesn't seem to work for me on Windows 10, VSCode, using node-sass-chokidar. In fact, it 's so bad that it completely crahes my npm run. If some one's one chokidar and reading this, take a look at this solution instead: https://github.com/michaelwayman/node-sass-chokidar/issues/14#issuecomment-391320086

However, I would still like to say that looking at your code this isn't really a fix, more something that should serve as a temporary patch. It can't be that a solution consists of: trying a thousand times and if that not works, throwing an error.