@seald-io/nedb - npm Package Compare versions

Comparing version 2.2.0 to 2.2.1

CHANGELOG.md

		@@ -9,2 +9,6 @@ # Changelog

		## [2.2.1] - 2022-01-18
		### Changed
		- [#20](https://github.com/seald/nedb/pull/20) storage.js: check fsync capability from return code rather than using process.platform heuristics (Thanks [@bitmeal](https://github.com/bitmeal)).

		## [2.2.0] - 2021-10-29
		@@ -11,0 +15,0 @@ ### Added

lib/storage.js

		@@ -53,11 +53,21 @@ /**

		// Windows can't fsync (FlushFileBuffers) directories. We can live with this as it cannot cause 100% dataloss
		// except in the very rare event of the first time database is loaded and a crash happens
		if (flags === 'r' && (process.platform === 'win32' \|\| process.platform === 'win64')) return callback(null)
		/**
		* Some OSes and/or storage backends (augmented node fs) do not support fsync (FlushFileBuffers) directories,
		* or calling open() on directories at all. Flushing fails silently in this case, supported by following heuristics:
		* + isDir === true
		* \|-- open(<dir>) -> (err.code === 'EISDIR'): can't call open() on directories (eg. BrowserFS)
		* `-- fsync(<dir>) -> (errFS.code === 'EPERM' \|\| errFS.code === 'EISDIR'): can't fsync directory: permissions are checked
		* on open(); EPERM error should only occur on fsync incapability and not for general lack of permissions (e.g. Windows)
		*
		* We can live with this as it cannot cause 100% dataloss except in the very rare event of the first time
		* database is loaded and a crash happens.
		*/

		fs.open(filename, flags, (err, fd) => {
		if (err) return callback(err)
		if (err) {
		return callback((err.code === 'EISDIR' && options.isDir) ? null : err)
		}
		fs.fsync(fd, errFS => {
		fs.close(fd, errC => {
		if (errFS \|\| errC) {
		if ((errFS \|\| errC) && !((errFS.code === 'EPERM' \|\| errFS.code === 'EISDIR') && options.isDir)) {
		const e = new Error('Failed to flush to storage')
		@@ -64,0 +74,0 @@ e.errorOnFsync = errFS

package.json

New alerts