How does broken mirror decal yellow
Gitbook can’t be hot loaded on Windows.
Gitbook is a powerful document writing tool that can easily output markdown into beautiful and elegant HTML. After gitbook serve starts the server, markdown ugly duckling turns into a beautiful HTML beauty.
If the source file changes and Windows fails to restart the server as expected, it throws an exception that immediately terminates Markdown’s makeup.
Restart after change in file README.md
Stopping server
events.js:183
throw er; // Unhandled 'error' event
^
Error: EPERM: operation not permitted, lstat 'F:\workspace\private-cloud-backup\gitbook-test\_book'
Copy the code
Yellow applique on mirror
Now take a look at markdown’s Cinderella transformation into HTML’s little sister!
$ gitbook serve --log=debug
Live reload server started on port: 35729
Press CTRL+C to quit ...
debug: readme found at README.md
debug: summary file found at SUMMARY.md
debug: cleanup folder "G:\sublime\gitbook-test\_book"
info: 7 plugins are installed
info: loading plugin "livereload". OK ... info: loading plugin"theme-default". OK info: found 1 pages info: found 0 asset files debug: calling hook"config"
debug: calling hook "init"debug: copy assets from theme C: \ Users \ snowdreams1006 \. Gitbook \ versions \ 3.2.3 \ node_modules \ gitbook - plugin - theme - the default \ _assets \ website... debug: Copy resources from plugin C:\Users\snowdreams1006\.gitbook\versions\3.2.3\node_modules\gitbook-plugin-livereload\book debug: generate page"README.md"
debug: calling hook "page:before"
debug: calling hook "page"
debug: index page README.md
debug: calling hook "finish:before"
debug: calling hook "finish"
debug: write search index
info: >> generation finished with success in 1.5s !
Starting server ...
Serving book on http://localhost:4000
Copy the code
According to the above output logs, we can analyze the basic running process of Gitbook.
- loading
readme
和summary
File, if presentglossary
Files are also loaded and deleted_book
directory
debug: readme found at README.md
debug: summary file found at SUMMARY.md
debug: cleanup folder "G:\sublime\gitbook-test\_book"
Copy the code
- Load dependent plug-ins. If no corresponding plug-in is found, an error message will be displayed, prompting you to run
gitbook install
Install the plug-in.
info: 7 plugins are installed
info: loading plugin "livereload". OK info: loading plugin"highlight". OK info: loading plugin"search". OK info: loading plugin"lunr". OK info: loading plugin"sharing". OK info: loading plugin"fontsettings". OK info: loading plugin"theme-default". OKCopy the code
- Scan pages and static resource files
info: found 1 pages
info: found 0 asset files
Copy the code
- Read the configuration file and initialize it
debug: calling hook "config"
debug: calling hook "init"
Copy the code
- Copy style resources and plug-in resources
debug: copy assets from theme C: \ Users \ snowdreams1006 \. Gitbook \ versions \ 3.2.3 \ node_modules \ gitbook - plugin - theme - the default \ _assets \ website debug: copy resources from plugin C: \ Users \ snowdreams1006 \. Gitbook \ versions \ 3.2.3 \ node_modules \ gitbook plugin - fontsettings \ assets debug: Copy resources from plugin C:\Users\snowdreams1006\.gitbook\versions\3.2.3\node_modules\gitbook-plugin-sharing\assets debug: Copy resources from plugin C:\Users\snowdreams1006\.gitbook\versions\3.2.3\node_modules\gitbook-plugin-lunr\assets debug: Copy resources from plugin C:\Users\snowdreams1006\.gitbook\versions\3.2.3\node_modules\gitbook-plugin-search\assets debug: Copy resources from plugin C:\Users\snowdreams1006\.gitbook\versions\3.2.3\node_modules\gitbook-plugin-highlight\ CSS debug: Copy resources from plugin C:\Users\snowdreams1006\.gitbook\versions\3.2.3\node_modules\gitbook-plugin-livereload\bookCopy the code
- Start generating individual pages, one by one
page:before
,page
The callback function is executed after all pages are executedfinish:before
和finish
Callback function.
debug: generate page "README.md"
debug: calling hook "page:before"
debug: calling hook "page"
debug: index page README.md
debug: calling hook "finish:before"
debug: calling hook "finish"
Copy the code
- Generate search files
debug: write search index
Copy the code
- After the startup is complete, a success message is displayed
Starting server ...
Serving book on http://localhost:4000
Copy the code
By default, when the server is started, it takes up two ports, one of which is the exposed 4000 port for the browser to access the project.
The other is port 35729, which is used to listen for local file changes and restart the server for hot loading.
After the local server starts up, we can go to http://localhost:4000 to preview the static site, and the Markdown source files are nicely morphed into HTML rich text files.
A broken mirror does not make up
Unfortunately,Windows hot loading can be a problem. If the server starts and the local file changes, the server will trigger the hot loading function and Error: EPERM: Operation not permitted
Markdown, who had just been transformed, was suddenly thrown back into his original shape and unable to appreciate the make-up, which was not a good experience!
Make up while looking in the mirror is to do the heart spectrum, adjust at any time, if you do not look in the mirror and directly make up, it is not ordinary people can do.
Gitbook started the local server to provide us with a mirror, but the hot load failed and broke the mirror, how to make up happily?
Restart after change in file README.md
Stopping server
debug: readme found at README.md
debug: summary file found at SUMMARY.md
debug: cleanup folder "G:\sublime\gitbook-test\_book"
events.js:174
throw er; // Unhandled 'error' event
^
Error: EPERM: operation not permitted, lstat 'G:\sublime\gitbook-test\_book'
Emitted 'error'event at: The at FSWatcher. _handleError (C: \ Users \ snowdreams1006 \. Gitbook \ versions \ 3.2.3 \ node_modules \ chokidar \ index js: 236:10) at ReaddirpReadable.emit (events.js:189:13) at Immediate.<anonymous> (C: \ Users \ snowdreams1006 \. Gitbook \ versions \ 3.2.3 \ node_modules \ chokidar \ node_modules \ readdirp \ stream - API js: 82:32) at runCallback (timers.js:705:18) at tryOnImmediate (timers.js:676:5) at processImmediate (timers.js:658:5)Copy the code
See a doctor to fix a broken mirror
Now that the problem has resurfaced, it’s time for the doctor’s office to try to fix it and turn Markdown into a beloved little sister.
When the _book directory is deleted and the directory is created again, the message EPERM: Operation not permitted is displayed.
Conan appendage.
Now let’s look at the status of the _book directory.
$ ls
gitbook-errorforwindows-preview.png README.md SUMMARY.md
Copy the code
There is no _book directory in the current project, which indicates that the _book directory was deleted when the error occurred, but the restart failed because the _book directory was not allowed to be created again for some reason.
However, this is just a manifestation of the phenomenon, the teacher told us to look through the phenomenon to see the essence, even if there is no _book file to start the server again will be successfully started and create _book file, so I really want only one!
The Gitbook console is lying!
Gitbook does not have the right to create the _book directory, so how do you explain the failure to create the _book directory after restarting the server?
debug: cleanup folder "G:\sublime\gitbook-test\_book"
events.js:174
throw er; // Unhandled 'error' event
^
Error: EPERM: operation not permitted, lstat 'G:\sublime\gitbook-test\_book'
Emitted 'error'event at: The at FSWatcher. _handleError (C: \ Users \ snowdreams1006 \. Gitbook \ versions \ 3.2.3 \ node_modules \ chokidar \ index js: 236:10) at ReaddirpReadable.emit (events.js:189:13) at Immediate.<anonymous> (C: \ Users \ snowdreams1006 \. Gitbook \ versions \ 3.2.3 \ node_modules \ chokidar \ node_modules \ readdirp \ stream - API js: 82:32) at runCallback (timers.js:705:18) at tryOnImmediate (timers.js:676:5) at processImmediate (timers.js:658:5)Copy the code
. Look at the first FSWatcher _handleError exception information: sed – n “223239 p” ~ /. Gitbook/versions / 3.2.3 / node_modules/chokidar/index. Js.
Analysis reveals that fswatcher._handleError is a private method that handles exception information and has little to do with the accident.
Administrator@snowdreams1006 MINGW64 /f/workspace/private-cloud-backup/gitbook-test (master)
$ sed -n "223,239p"~ /. Gitbook/versions / 3.2.3 / node_modules/chokidar/index/js/Private method: Common handlerfor errors
//
// * error - object, Error instance
//
// Returns the error if defined, otherwise the value of the
// FSWatcher instance's `closed` flag FSWatcher.prototype._handleError = function(error) { var code = error && error.code; var ipe = this.options.ignorePermissionErrors; if (error && code ! = = 'ENOENT' && code ! = = 'ENOTDIR'&& (! ipe || (code ! = = 'EPERM' && code ! = = 'EACCES')) ) this.emit('error', error); return error || this.closed; };Copy the code
Let’s go down and look at readDirPreadable.emit (events.js:189:13). There is no specific path for the file, so we cannot locate it.
Let’s look at the next Immediate.
: Sed – n “78 p” ~ /. Gitbook/versions / 3.2.3 / node_modules/chokidar/node_modules/readdirp/stream – API. Js
Administrator@snowdreams1006 MINGW64 /f/workspace/private-cloud-backup/gitbook-test (master)
$ sed -n "78 p"~ /. Gitbook/versions / 3.2.3 / node_modules/chokidar/node_modules/readdirp/stream - API. Js proto. _handleFatalError =function (err) {
var self = this;
setImmediate(function () {
if (self._paused) return self._errors.push(err);
if(! self._destroyed) self.emit('error', err);
});
}
function createStreamAPI () {
var stream = new ReaddirpReadable();
return {
stream : stream
, processEntry : stream._processEntry.bind(stream)
, done : stream._done.bind(stream)
, handleError : stream._handleError.bind(stream)
, handleFatalError : stream._handleFatalError.bind(stream)
};
}
Copy the code
Unfortunately, there is still no specific problem, so let’s follow up on a clue.
Timers.js :705:18 and events.js:189:13 do not show specific file locations, which would be nice if they were also in the Chokidar module.
Administrator@snowdreams1006 MINGW64 /f/workspace/private-cloud-backup/gitbook-test (master)
$ tree -P "events.js"-- the prune ~ /. Gitbook/versions / 3.2.3. / / / Users/Administrator/c gitbook/versions / 3.2.3 / └ ─ ─ node_modules ├ ─ ─ cheerio │ └ ─ ─ Node_modules │ └ ─ ─ jsdom │ └ ─ ─ lib │ └ ─ ─ jsdom │ └ ─ ─ level2 stores │ └ ─ ─ events. Js └ ─ ─ gitbook - plugin - theme - the default └ ─ ─ the SRC └ ─ ─ └─ core ├ ─ 12 directories, 2 files Administrator@snowdreams1006 MINGW64 /f/workspace/private-cloud-backup/gitbook-test (master) $ tree -P"timers.js"-- the prune ~ /. Gitbook/versions / 3.2.3. / / / Users/Administrator/c gitbook/versions / 3.2.3/0 directories, filesCopy the code
Git bash does not have a tree command. Git bash does not have a tree command.
After visual verification, it is found that events.js has no 174 line files at all, so most of these two files are not object files.
Since the target files cannot be found on the command line, use a professional search tool to search the system for these two files, using the Everything search tool.
However, it did not help, still no target file found.
After all, it wasn’t Conan who found out the truth
Turn to the official
Gitbook is an open source product, so I’m not the only one having problems, so go to Github and see if you’ve had the same problems as me.
Although I found like-minded partners, there was no solution, and even the official gave up, so what else do I have to miss?
Click to view gitbook Serve Livereload Error
diy
The biggest fear is not the bug, but found the bug but can not locate, although the console has an error message but did not find the real file!
Check the current system version and perform a version switchover to check whether the problem exists in other versions.
$gitbook --version CLI version: 2.3.2 gitbook version: 3.2.3Copy the code
- Upgrade to the latest version
Gitbook ls lists the currently installed version, while gitbook ls-remote lists the remote server version.
# list locally installed versions$gitbook ls gitbook Versions Installed: * 3.2.3 Run"gitbook update" to update to the latest version.
# list remote available versions$ gitbook ls-remote Available GitBook Versions: 4.0.0 - alpha. 6, 4.0.0 - alpha. 5, 4.0.0 - alpha. 4, 4.0.0 - alpha. 3, 4.0.0 - alpha. 2, 4.0.0 - alpha. 1, 3.2.2 and 3.2.3, 3.2.1, 3.2.0, 3.2.0 - pre. 1, 3.2.0 - pre. 0, 3.1.1, 3.1.0, 3.0.3, 3.0.2, 3.0.1, 3.0.0, 3.0.0 - pre. 15, 3.0.0 - pre. 14, 3.0.0 - pre. 13, 3.0.0 - pre. 12, 3.0.0 - pre. 11, 3.0.0 - pre. 10, 3.0.0 - pre. 9, 3.0.0 - pre. 8, 3.0.0 - pre. 7, 3.0.0 - pre. 6, 3.0.0 - pre. 5, 3.0.0 - pre. 4, 3.0.0 - pre. 3, 3.0.0 - pre. 2, 3.0.0 - pre. 1, 2.6.9, 2.6.8, 2.6.7, 2.6.6, 2.6.5, 2.6.4, 2.6.3, 2.6.2, 2.6.1, server, 2.5.2, 2.5.1, 2.5.0, 2.5.0 - beta. 7, 2.5.0 - beta. 6, 2.5.0 - beta. 5, 2.5.0 - beta. 4, 2.5.0 - beta. 3, 2.5.0 - beta. 2, 2.5.0 - beta. 1, 2.4.3, 2.4.2, against 2.4.1, 2.4.0 2.3.3, 2.3.2, 2.3.1, 2.3.0, 2.2.0, 2.1.0, 2.0.4, 2.0.3, 2.0.2, 2.0.1, 2.0.0, 2.0.0 - beta. 5, 2.0.0 - beta. 4, 2.0.0 - beta. 3, 2.0.0 - beta. 2, 2.0.0 - beta. 1, 2.0.0 - alpha. 9, 2.0.0 - alpha. 8, 2.0.0 - alpha. 7, 2.0.0 - alpha. 6. 2.0.0-alpha.5, 2.0.0-alpha.4, 2.0.0-alpha.3, 2.0.0-alpha.2, 2.0.0-alpha.1 Tags: latest: 2.6.9 Pre: 4.0.0-alpha.6Copy the code
The latest release is 3.2.3, which is the version we have installed locally, so it’s time to test 4.0.0-alpha.6.
4.0.0-alpha.6 is a bit of a surprise. According to version management conventions, the version number usually consists of three parts: the first part represents major upgrades that are not compatible, the second part represents feature upgrades that are compatible with the trunk, and the third part is minor fixes.
A direct jump from 3.2.3 to 4.0.0-alpha.6 means a major refactoring of the Gitbook!
Well, try downloading it first!
Gitbook Fetch download and Gitbook Update. You can experience the latest version in both ways. The download mode is selected here to facilitate switching between different versions.
# Download version 4.0.0-alpha.6$gitbook fetch 4.0.0-alpha.6 Installing Gitbook 4.0.0-alpha.6 [email protected] C: \ Users \ SNOWDR ~ 1 \ AppData \ Local hsrxnvtcrfeh \ node_modules \ \ Temp \ TMP - 8912 gitbook ├ ─ ─ [email protected] ├ ─ ─ [email protected] ├── heavy exercises ── heavy exercises [email protected], [email protected], [email protected], [email protected], [email protected],source[email protected], [email protected], [email protected], [email protected], [email protected], [email protected] [email protected], [email protected], [email protected], [email protected]) GitBook 4.0.0-alpha.6 has been installedCopy the code
Take a look at the locally installed version of Gitbook and make sure you use the latest 4.0.0-alpha.6 version when you run it.
# list locally installed versions$gitbook ls gitbook Versions Installed: * 4.0.0-alpha.6 3.2.3 Run"gitbook update" to update to the latest version.
# list the version currently in use$gitbook Current Gitbook version is 3.2.3Copy the code
Gitbook serve –gitbook=4.0.0-alpha.6 –log=debug Run 4.0.0-alpha.6 and print debug level logs.
~\.gitbook\versions\4.0.0-alpha.6\node_modules\gitbook-plugin-livereload\_assets\plugin.js cannot be opened.
Recall the version number specification, possibly v3 to V4 change a large, incompatible version of the bar, re-initialize the project to try!
Initialize the project and specify 'gitbook' to run the version$gitbook init --gitbook=4.0.0-alpha.6 Warning: Accessing PropTypes via the main React package is deprecated, and will be removedin React v16.0. Use the latest available v15.* prop-types package from npm instead. For info on usage, compatibility, migration and more, see https://fb.me/prop-types-docs
info: create SUMMARY.md
info: initialization is finished
Copy the code
However, it still reported the same error and still failed to start.
$gitbook serve --gitbook=4.0.0-alpha.6 --log=debug Warning: Accessing PropTypes via the main React package is deprecated, and will be removedinReact V16.0. Use the latest available v15.* prop-types package from NPM instead. For info on usage, compatibility, migration and more, see https://fb.me/prop-types-docs Live reload server started on port: 35729 Press CTRL+C to quit ... . Error: ENOENT: no such file or directory, open'C: \ Users \ snowdreams1006 \. Gitbook \ versions \ 4.0.0 - alpha. 6 \ node_modules \ gitbook plugin - livereload \ _assets \ plugin js'
Copy the code
This road is blocked, and then another, since up can not handle, that back down will have the result?
- The fallback version
The current version is 3.2.3, the latest beta version is 4.0.0-alpha.6, however, the last version submitted is 2.6.9?
Why did gitbook- CI manage the gitbook version number suddenly drop, is there something fishy, is there a bug fixed?
$ gitbook ls-remote Available GitBook Versions: 4.0.0 - alpha. 6, 4.0.0 - alpha. 5, 4.0.0 - alpha. 4, 4.0.0 - alpha. 3, 4.0.0 - alpha. 2, 4.0.0 - alpha. 1, 3.2.2 and 3.2.3, 3.2.1, 3.2.0, 3.2.0 - pre. 1, 3.2.0 - pre. 0, 3.1.1, 3.1.0, 3.0.3, 3.0.2, 3.0.1, 3.0.0, 3.0.0 - pre. 15, 3.0.0 - pre. 14, 3.0.0 - pre. 13, 3.0.0 - pre. 12, 3.0.0 - pre. 11, 3.0.0 - pre. 10, 3.0.0 - pre. 9, 3.0.0 - pre. 8, 3.0.0 - pre. 7, 3.0.0 - pre. 6, 3.0.0 - pre. 5, 3.0.0 - pre. 4, 3.0.0 - pre. 3, 3.0.0 - pre. 2, 3.0.0 - pre. 1, 2.6.9, 2.6.8, 2.6.7, 2.6.6, 2.6.5, 2.6.4, 2.6.3, 2.6.2, 2.6.1, server, 2.5.2, 2.5.1, 2.5.0, 2.5.0 - beta. 7, 2.5.0 - beta. 6, 2.5.0 - beta. 5, 2.5.0 - beta. 4, 2.5.0 - beta. 3, 2.5.0 - beta. 2, 2.5.0 - beta. 1, 2.4.3, 2.4.2, against 2.4.1, 2.4.0 2.3.3, 2.3.2, 2.3.1, 2.3.0, 2.2.0, 2.1.0, 2.0.4, 2.0.3, 2.0.2, 2.0.1, 2.0.0, 2.0.0 - beta. 5, 2.0.0 - beta. 4, 2.0.0 - beta. 3, 2.0.0 - beta. 2, 2.0.0 - beta. 1, 2.0.0 - alpha. 9, 2.0.0 - alpha. 8, 2.0.0 - alpha. 7, 2.0.0 - alpha. 6. 2.0.0-alpha.5, 2.0.0-alpha.4, 2.0.0-alpha.3, 2.0.0-alpha.2, 2.0.0-alpha.1 Tags: latest: 2.6.9 Pre: 4.0.0-alpha.6Copy the code
With these questions in mind, why not download version 2.6.9 and see if it can be hot loaded?
Gitbook serve –log=debug –gitbook=2.6.9
$gitbook serve --log=debug --gitbook=2.6.9 Error loading version latest: Error: Cannot find module'q'at Function.Module._resolveFilename (internal/modules/cjs/loader.js:582:15) at Function.Module._load (internal/modules/cjs/loader.js:508:25) at Module.require (internal/modules/cjs/loader.js:637:17) at require (internal/modules/CJS/helpers. Js: ") at the Object. The < anonymous > (C: \ Users \ myHome \. Gitbook \ versions \ 2.6.9 \ lib \ index js: ") at Module._compile (internal/modules/cjs/loader.js:701:30) at Object.Module._extensions.. js (internal/modules/cjs/loader.js:712:10) at Module.load (internal/modules/cjs/loader.js:600:32) at tryModuleLoad (internal/modules/cjs/loader.js:539:12) at Function.Module._load (internal/modules/cjs/loader.js:531:3) TypeError: Cannotread property 'commands' of null
Copy the code
Return to the scene
Now, let’s refocus on the original crime scene, and this time it’s up to us, to feed ourselves or starve to death!
Stopping server
debug: readme found at README.md
debug: summary file found at SUMMARY.md
debug: cleanup folder "G:\sublime\private-cloud-backup\gitbook-test\_book"
events.js:174
throw er; // Unhandled 'error' event
^
Error: EPERM: operation not permitted, lstat 'G:\sublime\private-cloud-backup\gitbook-test\_book'
Emitted 'error'event at: The at FSWatcher. _handleError (C: \ Users \ myHome \. Gitbook \ versions \ 3.2.3 \ node_modules \ chokidar \ index js: 236:10) at ReaddirpReadable.emit (events.js:189:13) at Immediate.<anonymous> (C: \ Users \ myHome \. Gitbook \ versions \ 3.2.3 \ node_modules \ chokidar \ node_modules \ readdirp \ stream - API js: 82:32) at runCallback (timers.js:705:18) at tryOnImmediate (timers.js:676:5) at processImmediate (timers.js:658:5)Copy the code
There is only one section on the truth about the error described above, which concludes that gitbook had an accident when deleting the _book folder and creating a new _book folder.
What happens if this behavior happens not by Gitbook but by our manual intervention, that is, when the _book folder is manually deleted after the local server is successfully started and just before hot loading occurs?
My guess is:
Gitbook’s hot loading mechanism listens for changes in the local file directory system, stops the server, and then restarts it.
When we manually delete the _book folder, gitbook will suddenly find that there is no _book folder at the moment of triggering the restart of the server, so it will not delete or create an exception. It is equivalent to directly creating the _book folder, which turns hot loading into initial startup mode.
I hope god does not live up to me, if not, can only look at the source logic to find bugs!
Guess what? it works !
-
In the experiment,gitbook serve –log=debug after starting the local server, if the local file changes will fail to restart!
-
However, if you delete the _book directory immediately after starting the local server, you can successfully restart the service when the local files are modified.
At this point, the solution is to delete the _book directory immediately after starting the service.
Not a perfect summary
If the local file is changed after the Gitbook service is started on Windows, hot add will fail.
If you delete the _book directory immediately after starting the server, you will be able to restart without any further changes to the local files.
The root cause of the problem has not yet been found, and next time I will dig into the source code to explore what exactly is the problem causing the Windows system to fail to restart.
Deleting the _book directory in time isn’t a great solution, but at least Markdown Cinderella can dress up as HTML sister again!