Giter Club home page Giter Club logo

write-file-atomic's Introduction

write-file-atomic

This is an extension for node's fs.writeFile that makes its operation atomic and allows you set ownership (uid/gid of the file).

writeFileAtomic(filename, data, [options], [callback])

Description:

Atomically and asynchronously writes data to a file, replacing the file if it already exists. data can be a string or a buffer.

Options:

  • filename String
  • data String | Buffer
  • options Object | String
    • chown Object default, uid & gid of existing file, if any
      • uid Number
      • gid Number
    • encoding String | Null default = 'utf8'
    • fsync Boolean default = true
    • mode Number default, from existing file, if any
    • tmpfileCreated Function called when the tmpfile is created
  • callback Function

Usage:

var writeFileAtomic = require('write-file-atomic')
writeFileAtomic(filename, data, [options], [callback])

The file is initially named filename + "." + murmurhex(__filename, process.pid, ++invocations). Note that require('worker_threads').threadId is used in addition to process.pid if running inside of a worker thread. If writeFile completes successfully then, if passed the chown option it will change the ownership of the file. Finally it renames the file back to the filename you specified. If it encounters errors at any of these steps it will attempt to unlink the temporary file and then pass the error back to the caller. If multiple writes are concurrently issued to the same file, the write operations are put into a queue and serialized in the order they were called, using Promises. Writes to different files are still executed in parallel.

If provided, the chown option requires both uid and gid properties or else you'll get an error. If chown is not specified it will default to using the owner of the previous file. To prevent chown from being ran you can also pass false, in which case the file will be created with the current user's credentials.

If mode is not specified, it will default to using the permissions from an existing file, if any. Expicitly setting this to false remove this default, resulting in a file created with the system default permissions.

If options is a String, it's assumed to be the encoding option. The encoding option is ignored if data is a buffer. It defaults to 'utf8'.

If the fsync option is false, writeFile will skip the final fsync call.

If the tmpfileCreated option is specified it will be called with the name of the tmpfile when created.

Example:

writeFileAtomic('message.txt', 'Hello Node', {chown:{uid:100,gid:50}}, function (err) {
  if (err) throw err;
  console.log('It\'s saved!');
});

This function also supports async/await:

(async () => {
  try {
    await writeFileAtomic('message.txt', 'Hello Node', {chown:{uid:100,gid:50}});
    console.log('It\'s saved!');
  } catch (err) {
    console.error(err);
    process.exit(1);
  }
})();

writeFileAtomicSync(filename, data, [options])

Description:

The synchronous version of writeFileAtomic.

Usage:

var writeFileAtomicSync = require('write-file-atomic').sync
writeFileAtomicSync(filename, data, [options])

write-file-atomic's People

Contributors

102 avatar charliehess avatar coreyfarrell avatar darcyclarke avatar dependabot[bot] avatar develar avatar ferm10n avatar geekgonecrazy avatar github-actions[bot] avatar gvozd avatar iarna avatar isaacs avatar jimmywarting avatar kevva avatar lukeapage avatar lukekarrys avatar mcollina avatar mojavelinux avatar novemberborn avatar othiym23 avatar sheerun avatar simenb avatar thefourtheye avatar wraithgar avatar zkat avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

write-file-atomic's Issues

worker_threads missing on nodejs 8 breaks firebase-admin

The meteor framework runs nodejs 8 so i can't change the nodejs version.
As a work around i am using [email protected]

├─┬ [email protected]

│ ├─┬ @google-cloud/[email protected]
│ │ ├─┬ @google-cloud/[email protected]
│ │ ├─┬ [email protected]
│ │ │ ├─┬ [email protected]
│ │ │ │ ├── [email protected] deduped
└─┬ [email protected]
  ├── [email protected]
  ├── [email protected]
  └── [email protected]

[FEATURE] Restore creation date of updated file

When using this library you can't differ between updated date and created date of a file. It will be always the same (updated date). Would be nice to restore the created date if possible.

Changes ownership to $USER on update.

write-file-atomic changes the ownership of the file it's writing to the current user, even if no chown option is set.

Steps to reproduce:

# Install write-file-atomic.
$ npm install [email protected]

# Create example script that writes to a new file with no other options.
$ echo 'require("write-file-atomic")("hello.txt", "hello!\n", ()=>0)' > example.js

# Run script as current user.
$ node example.js

# Observe that the owner/group is current user (expected).
$ ls -al hello.txt
-rw-rw-r-- 1 jimbo jimbo 6 May 12 05:45 hello.txt

# Re-run the example script as root.
$ sudo node example.js

# Expect owner/group unchanged, observe that it's now root.
$ ls -al hello.txt
-rw-r--r-- 1 root root 7 May 12 05:50 hello.txt

Note: If you installed node via nvm, then running sudo node example.js probably won't work due to path issues. You can overcome this and still run as sudo by overriding the PATH var:

$ sudo PATH=$PATH bash -c 'node example.js'

Tested on Ubuntu 14.04 with Node v6.1.0.

EPERM: operation not permitted

Since updating to v3 I get this error:

EPERM: operation not permitted, rename 'C:\Users\Tomas\AppData\Roaming\MiArt\var\config\default.json.727851267' -> 'C:\Users\Tomas\AppData\Roaming\MiArt\var\config\default.json'

I use write-file-atomic to save app config inside Electron v5 app. This error only happens on Windows, on MacOS everything works fine. Also if I downgrade back to 2.4.3, it works on Windows again.

Anything I can do to help solve this issue? Or is it something on my end?

[BUG] Cannot read property 'getFileName' of undefined

Sry, but the issue template needs to change... too much weird stuff to fill in.

I tried downloading the source and running npm i && npm run test from scratch. But it fails

jimmy.warting@tr-c02zj2p learning-atomic % npm run test

> [email protected] test
> tap

TypeError: Cannot read property 'getFileName' of undefined
    at module.exports (/Users/jimmy.warting/git/learning-atomic/node_modules/tap/node_modules/caller-path/index.js:4:40)
    at importJSX (/Users/jimmy.warting/git/learning-atomic/node_modules/tap/node_modules/import-jsx/index.js:24:46)
    at module.exports (/Users/jimmy.warting/git/learning-atomic/node_modules/tap/node_modules/treport/lib/index.js:13:18)
    at exports.makeReporter (/Users/jimmy.warting/git/learning-atomic/node_modules/tap/bin/run.js:422:23)
    at runTests (/Users/jimmy.warting/git/learning-atomic/node_modules/tap/bin/run.js:744:3)
    at mainAsync (/Users/jimmy.warting/git/learning-atomic/node_modules/tap/bin/run.js:244:5)
TAP version 13

fyi, i use node v16.6.2

The final `fsync` makes it 16 times slower

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

I'm writing 6,700 files.
If I pass fsync: false to the options, it takes 9 seconds.
If I don't, it defaults to true, and it takes 152 seconds (!).

From the docs I see this:

If the fsync option is false, writeFile will skip the final fsync call.

Could you explain how important this final fsync call is? I'm considering to disable it.

Expected Behavior

I wish to have it faster, or understand whether it's safe to cancel the fsync.

Steps To Reproduce

try to write lots of files ( > 1000) to see the issue clearly.

Environment

  • npm: 8.1.2
  • Node: v16.13.2
  • OS: Mac OS 12.6
  • platform: Mac

1.3.3 breaks my build

(rj-titan)root@oglach-0:/home/buildbot/jenkins/workspace/rea-jet-firmware-etx/origin/build/3.72/psens_fix/titan-web/titan-gui-web# ./node_modules/.bin/typings install

TypeError: Not an integer
    at Object.fs.writeSync (fs.js:528:18)
    at Function.writeFileSync [as sync] (/home/buildbot/jenkins/workspace/rea-jet-firmware-etx/origin/build/3.72/psens_fix/titan-web/titan-gui-web/node_modules/typings/node_modules/typings-core/node_modules/configstore/node_modules/write-
file-atomic/index.js:114:10)
    at Object.create.all.set (/home/buildbot/jenkins/workspace/rea-jet-firmware-etx/origin/build/3.72/psens_fix/titan-web/titan-gui-web/node_modules/typings/node_modules/typings-core/node_modules/configstore/index.js:63:21)
    at Object.Configstore (/home/buildbot/jenkins/workspace/rea-jet-firmware-etx/origin/build/3.72/psens_fix/titan-web/titan-gui-web/node_modules/typings/node_modules/typings-core/node_modules/configstore/index.js:28:11)
    at Object.<anonymous> (/home/buildbot/jenkins/workspace/rea-jet-firmware-etx/origin/build/3.72/psens_fix/titan-web/titan-gui-web/node_modules/typings/node_modules/typings-core/dist/utils/store.js:5:19)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (/home/buildbot/jenkins/workspace/rea-jet-firmware-etx/origin/build/3.72/psens_fix/titan-web/titan-gui-web/node_modules/typings/node_modules/typings-core/dist/utils/fs.js:29:15)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)

Rolling back manually to [email protected] fixes it.

[Error] Error on npm start

pr6

Error: No valid exports main found for 'C:\Users\USER\Desktop\HTML\react\learn-react\node_modules\postcss-safe-parser\node_modules\postcss'
←[90m at resolveExportsTarget (internal/modules/cjs/loader.js:625:9)←[39m
←[90m at applyExports (internal/modules/cjs/loader.js:502:14)←[39m
←[90m at resolveExports (internal/modules/cjs/loader.js:551:12)←[39m
←[90m at Function.Module._findPath (internal/modules/cjs/loader.js:657:22)←[39m
←[90m at Function.Module._resolveFilename (internal/modules/cjs/loader.js:960:27)←[39m
←[90m at Function.Module._load (internal/modules/cjs/loader.js:855:27)←[39m
←[90m at Module.require (internal/modules/cjs/loader.js:1033:19)←[39m
←[90m at require (internal/modules/cjs/helpers.js:72:18)←[39m
at Object. (C:\Users\USER\Desktop\HTML\react\learn-react\node_modules\←[4mpostcss-safe-parser←[24m\lib\safe-parse.js:1:17)
←[90m at Module._compile (internal/modules/cjs/loader.js:1144:30)←[39m {
code: ←[32m'MODULE_NOT_FOUND'←[39m
}
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] start: react-scripts start
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\USER\AppData\Roaming\npm-cache_logs\2020-11-01T18_25_06_686Z-debug.log

node -v : v13.6.0
npm -v : 6.14.8
Windows 7 Proffessional

suggestions: remove two package

write-file-atomic/index.js

Lines 109 to 113 in 393cdc6

if (isTypedArray(data)) {
data = typedArrayToBuffer(data)
}
if (Buffer.isBuffer(data)) {
await promisify(fs.write)(fd, data, 0, data.length, 0)

Node v10.10 supports writing any typed array (ref)
So maybe it's possible to remove two dependencies:

  • is-typedarray
  • and typedarray-to-buffer

can send a pr if you like...

Does not support FIPS compliance and actually breaks NPM

When NodeJS is compiled for FIPS-compliance, write-file-atomic actually breaks NPM.

When NPM attempts to write the local cache file .cache.json using writeFile from the library, it throws the following:

fips_md.c(146): OpenSSL internal error, assertion failed: Digest update previous FIPS forbidden algorithm error ignored
Aborted

Instead of hardcoding md5 hash for the temporary name, consider moving to something higher like sha1 at a minimum or check for FIPs compliance and make it variable. I tested by moving the function createhash() call to sha1 and it proceeds fine.

writeFileSync can corrupt file if crash occurs immediately after write

We've been using NotMyFault to trigger blue-screens on Windows, and have found that even after the fs.renameSync has "finished," if you trigger a blue-screen the target file is corrupted.

We're using this library through node-localstorage. From http://www.daveeddy.com/2013/03/26/synchronous-file-io-in-nodejs/:

fs.writeFileSync is synchronous in the sense that it blocks the event loop while it executes. It does NOT ask the Kernel to do a synchronous write to the underlying file system.

One way to make this work is to use fsync to flush buffers, which is what some Node.js databases are doing. There's a proof of concept of this at https://github.com/CharlieHess/crash-safe-write-file.

Support URL for path param

In recent versions of node, fs.writeFile() supports file:// based URL objects. It would be nice if this module could support that as well, for better drop-in support.

writeFile may leak 'fd'

A file descriptor to write to 'tmpfile' is opened in 'thenWriteFile', but if subsequently fs.write(fd, ...) in 'write' fails then the file descriptor is not closed.
Only 'syncAndClose' attempts to close the file descriptor, but it is not consistently closed.

This may result in many open file descriptors, increase EMFILE errors and cause slowdown because 'graceful-fs' will queue opening files. In the worst-case all open file requests will be queued forever.

[Bug] Writing to exfat drive on linux

What / Why

I'm writing to an external exfat formatted drive on linux. This is a root mounted drive with no permissions system, so everyfile is owned by root, with full rw access to all users. So I have read, write access to the file.

write-file-atomic is trying to set the ownership of the file.
chown: changing ownership of '/media/sandisk/config.json': Operation not permitted

I know that you advice to pass false to the permission option, however this is a 2nd level dependancy, so I'm not actually using this library directly. I'm using
json-future, which has a dependancy for write-json-file, which is using write-file-atomic.

I think if write-file-atomic is just going to set the uid to the existing user, it could catch this error and squash it, as chown failing has no impact.

[FEATURE] Support for custom fs

What / Why

Support for passing in a custom fs (eg. memfs for writing to memory).

Currently using it for running fs related tests in-memory.

How

Current Behavior

writeFileAtomic(filePath, data, { mode: ..., chown: ... });

Expected Behavior

const fs = new memfs.Volume();
writeFileAtomic(filePath, data, { mode: ..., chown: ..., fs });

Code issues

Some notes:

  1. Unnecessary 'fs.unlink' in 'fail' in 'writeFile'. 'removeOnExit()' already unlinks the file.
  2. Synchronous 'fs.unlinkSync' in asynchronous 'writeFile'. tmpfile should be unlinked asynchronously in all exit paths of 'writeFile'.

Add changelogs for v3

Hi,

Please, can you update CHANGELOG.md with 3.0.0 changes and breaking changes ?

As I see, the only "big" changes are done in this commit: 5361569. It seems to not have special changes, nor breaking expect the drop support for node 6 and before..

Thanks

Symlinks bug

Suppose such case:

/mnt/readonly_fs/some_symlink -> /var/real_file.

So, atomic_write('/mnt/readonly_fs/some_symlink') will try to create temporary file in /mnt/readonly_fs/. This is BUG. It should create temporary file in /var and replace /var/real_file accordingly.

The library have to resolve path recursively to get final path without any symlinks. It must do it before any operations.

but how to do a read and a write atomically?

I see the value in writing atomically, but are there any suggestions for

1. locking a file
2. reading from it
3. writing to it
4. releasing the lock

how do we do this (with Node.js)?

thanks for any help!

[BUG] Class private methods are not enabled. Please add @babel/plugin-proposal-private-methods to your configuration.

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

node_modules/write-file-atomic/node_modules/signal-exit/dist/cjs/index.js: Class private methods are not enabled. Please add @babel/plugin-proposal-private-methods to your configuration.
210 | this.#emitter.count -= 1;
211 | }

212 | #processReallyExit(code) {
| ^
213 | /* c8 ignore start */
214 | if (!processOk(this.#process)) {
215 | return 0;

Expected Behavior

it should not require @babel/plugin-proposal-private-methods

Steps To Reproduce

try to use write-file-atomic in a jscodeshift env

Environment

  • npm: 9.6.4
  • Node: 20.1.0
  • OS: os x
  • platform: macbook pro

Jest run fails with EBADF: bad file descriptor

We have recently had the issue on CI when run jest in parallel.
jest: failed to cache transform results in: C:/Temp/jest/jest-transform-cache-
Failure message: EBADF: bad file descriptor, close
at Error (native)
at Object.closeSync (node_modules/graceful-fs/graceful-fs.js:52:27)
at Function.writeFileSync [as sync] (node_modules/write-file-atomic/index.js:228:16)

In the jest github, solution is rollback write-file-atomic to 2.4.1.
jestjs/jest#7709.

I am wondering this is a bug of the package that need to be fixed?

reduce package size

Remove is-typedarray & typedarray-to-buffer to reduce dependencies?

Native solution:

if (ArrayBuffer.isView(arr)) {
  data = Buffer.from(arr.buffer, arr.byteOffset, arr.byteOffset + arr.byteLength)
}

Better yet - don't convert it to a buffer. Node v10 supports writing any typedArray with the fs

worker_threads missing leads to webpack warning

A project that I use (electron-json-storage) has begun using this project, and since they began using it a build warning has appeared when using webpack and angular AOT:
electron-userland/electron-json-storage#126

copying relevant output here:

WARNING in ./node_modules/electron-json-storage/node_modules/write-file-atomic/index.js
Module not found: Error: Can't resolve 'worker_threads' in '/{path_to_my_project}/node_modules/electron-json-storage/node_modules/write-file-atomic'
 @ ./node_modules/electron-json-storage/node_modules/write-file-atomic/index.js
 @ ./node_modules/electron-json-storage/lib/storage.js
 @ {where my import is}

I see now based on the code that this is expected:
https://github.com/npm/write-file-atomic/blob/master/index.js#L17

Is this avoidable in some way? It seems to have no ill effects, but I'd like to be able to build without the warning if possible.

Weird problems with session-file-storage

Hello,

I am not quite sure this really fits here, and maybe it's not even an write-file-atomic issue (difficult to tell). But whatever: The update from 1.3.1 to 1.3.4 seems to cause valery-barysok/session-file-store#61, and subsequently also caused Haufe-Lexware/wicked.haufe.io#72.

For now, I had to pin version 1.3.1 (that fixes it for me) in my parent package.json, so that session-file-store also picks version 1.3.1.

Presumably, the following happens: The session file store tries to persist the session data, but that doesn't happen immediately, so that subsequent (more or less parallel) calls to the backend overwrites the session information, taking out e.g. the user information from it --> The user is not logged in, even if the login succeeded. Sometimes, the state was persisted, but not reflected immediately. Likewise with logging out (which sometimes was simply not possible).

I will check whether this can be fixed by rolling forward to 2.x, and if so, file a PR for session-file-store.

Best regards, Martin

getTmpname always returns the same hash

The problem is because process.id and invocation are not string, convert to string will fix the problem, for example :
return filename + '.' + MurmurHash3(__filename).hash(process.pid + '').hash((++invocations) + '').result()

Context: this library is used by configstore, which is used by bower, when running bower install in parallel, this problem causes the issue

`writeFileSync` may error with `cross-device link not permitted` on Windows

Windows apps installed via .appx may be installed to any drive the user chooses. From what I understand, when an appx application is executed, the file system is virtualized; Windows lies to the application about where it is running from, and when the application accesses a file, Windows proxies the calls across from the virtualized location to the actual location.

Example: if Windows is installed on C:, I can install an AppX application on D:. When the application is launched, Windows will the application CWD will be C:\Users\David\AppData\Roaming\{AppName} instead of somewhere on the D: drive.

(note: I could be wrong about what Windows is really doing here!)

All that to say... the following call to fs.renameSync may fail with a cross-device link not permitted error. I wish Windows would handle this internally, as this really seems more like a Windows bug than bug in write-file-atomic to me.

fs.renameSync(tmpfile, filename)

A potential solution may be to first try the rename, then try a copy + delete operation if that rename fails.

related issue: trufflesuite/ganache-ui#1943

[ERROR] <npm Start no Work>

pr6

I download React i got The files but when i want to start it it's not work with me
also i got some error and when i go to npm-catche there some debugs i uninstall many times and try again also same error

######## AppData\Roaming\npm-cache_logs debges

0 info it worked if it ends with ok
1 verbose cli [
1 verbose cli 'C:\Program Files\nodejs\node.exe',
1 verbose cli 'C:\Users\USER\AppData\Roaming\npm\node_modules\npm\bin\npm-cli.js',
1 verbose cli 'start'
1 verbose cli ]
2 info using [email protected]
3 info using [email protected]
4 verbose run-script [ 'prestart', 'start', 'poststart' ]
5 info lifecycle [email protected]prestart: [email protected]
6 info lifecycle [email protected]
start: [email protected]
7 verbose lifecycle [email protected]start: unsafe-perm in lifecycle true
8 verbose lifecycle [email protected]
start: PATH: C:\Users\USER\AppData\Roaming\npm\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin;C:\Users\USER\Desktop\HTML\react\learn-react\node_modules.bin;C:\Program Files\nodejs;C:\Program Files (x86)\Yarn\bin;C:\Program Files\nodejs;C:\Program Files\nodejs;C:\Program Files (x86)\Yarn\bin;C:\Program Files\nodejs
9 verbose lifecycle [email protected]start: CWD: C:\Users\USER\Desktop\HTML\react\learn-react
10 silly lifecycle [email protected]
start: Args: [ '/d /s /c', 'react-scripts start' ]
11 silly lifecycle [email protected]start: Returned: code: 1 signal: null
12 info lifecycle [email protected]
start: Failed to exec start script
13 verbose stack Error: [email protected] start: react-scripts start
13 verbose stack Exit status 1
13 verbose stack at EventEmitter. (C:\Users\USER\AppData\Roaming\npm\node_modules\npm\node_modules\npm-lifecycle\index.js:332:16)
13 verbose stack at EventEmitter.emit (events.js:321:20)
13 verbose stack at ChildProcess. (C:\Users\USER\AppData\Roaming\npm\node_modules\npm\node_modules\npm-lifecycle\lib\spawn.js:55:14)
13 verbose stack at ChildProcess.emit (events.js:321:20)
13 verbose stack at maybeClose (internal/child_process.js:1028:16)
13 verbose stack at Process.ChildProcess._handle.onexit (internal/child_process.js:286:5)
14 verbose pkgid [email protected]
15 verbose cwd C:\Users\USER\Desktop\HTML\react\learn-react
16 verbose Windows_NT 6.1.7601
17 verbose argv "C:\Program Files\nodejs\node.exe" "C:\Users\USER\AppData\Roaming\npm\node_modules\npm\bin\npm-cli.js" "start"
18 verbose node v13.6.0
19 verbose npm v6.14.8
20 error code ELIFECYCLE
21 error errno 1
22 error [email protected] start: react-scripts start
22 error Exit status 1
23 error Failed at the [email protected] start script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]

######## The Terminal cmd command Error

Error: No valid exports main found for 'C:\Users\USER\Desktop\HTML\react\learn-react\node_modules\postcss-safe-parser\node_modules\postcss'
←[90m at resolveExportsTarget (internal/modules/cjs/loader.js:625:9)←[39m
←[90m at applyExports (internal/modules/cjs/loader.js:502:14)←[39m
←[90m at resolveExports (internal/modules/cjs/loader.js:551:12)←[39m
←[90m at Function.Module._findPath (internal/modules/cjs/loader.js:657:22)←[39m
←[90m at Function.Module._resolveFilename (internal/modules/cjs/loader.js:960:27)←[39m
←[90m at Function.Module._load (internal/modules/cjs/loader.js:855:27)←[39m
←[90m at Module.require (internal/modules/cjs/loader.js:1033:19)←[39m
←[90m at require (internal/modules/cjs/helpers.js:72:18)←[39m
at Object. (C:\Users\USER\Desktop\HTML\react\learn-react\node_modules\←[4mpostcss-safe-parser←[24m\lib\safe-parse.js:1:17)
←[90m at Module._compile (internal/modules/cjs/loader.js:1144:30)←[39m {
code: ←[32m'MODULE_NOT_FOUND'←[39m
}
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] start: react-scripts start
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\USER\AppData\Roaming\npm-cache_logs\2020-11-01T18_25_06_686Z-debug.log

node -v : v13.6.0
npm -v : 6.14.8
Windows 7 Proffessional

EPERM error on Windows when multiple processes try to write the same file

When write-file-atomic is used by multiple processes (e.g. in worker-farm) it can run into a race condition where the same file is being written/renamed concurrently. On Windows it causes the following error:

Error: EPERM: operation not permitted, rename '...' -> '...'

#22 seems to address this issue for async writes within the same process, but the issue still exists for parallel sync/async writes.

Here's a repro that demonstrates the problem: https://github.com/asapach/write-atomic-issue

Original issue: jestjs/jest#4444

What means "atomic" in this context?

Hello guys,
I'd like to understand better what means "atomic" in this context. Mostly sure atomic here means exactly the same thing that atomic in general programming, but that's what I don't know.

Could you guys help me understanding that?

Return a promise

Since the library is already written with promises, it'd be nice if it could return a promise. I generally prefer promises over callbacks, because they're really nice to work with in conjunction with async functions 😋

Remove tests from npm install

The package.json should include a "files" field for whitelisting the index.js file to be included on an install. This will exclude all extraneous js files like the test directory.

EPERM on Windows when running in parallel

Running del in parallel on our CI running on Windows, throws EPERM. I was told to create an issue here.

Ref yeoman/update-notifier#68

Our stacktrace:

error   31-Mar-2016 14:15:50    Error: EPERM: operation not permitted, rename 'C:\Windows\system32\config\systemprofile\.config\configstore\update-notifier-del-cli.json.1874881583' -> 'C:\Windows\system32\config\systemprofile\.config\configstore\update-notifier-del-cli.json'
error   31-Mar-2016 14:15:50        at Error (native)
error   31-Mar-2016 14:15:50        at Object.fs.renameSync (fs.js:681:18)
error   31-Mar-2016 14:15:50        at Function.writeFileSync [as sync] (D:\Bamboo\bamboo-home\xml-data\build-dir\SON-FRON-JOB1\code\node_modules\write-file-atomic\index.js:39:8)
error   31-Mar-2016 14:15:50        at Object.create.all.set (D:\Bamboo\bamboo-home\xml-data\build-dir\SON-FRON-JOB1\code\node_modules\configstore\index.js:63:21)
error   31-Mar-2016 14:15:50        at Object.Configstore (D:\Bamboo\bamboo-home\xml-data\build-dir\SON-FRON-JOB1\code\node_modules\configstore\index.js:28:11)
error   31-Mar-2016 14:15:50        at new UpdateNotifier (D:\Bamboo\bamboo-home\xml-data\build-dir\SON-FRON-JOB1\code\node_modules\update-notifier\index.js:34:17)
error   31-Mar-2016 14:15:50        at module.exports (D:\Bamboo\bamboo-home\xml-data\build-dir\SON-FRON-JOB1\code\node_modules\update-notifier\index.js:108:23)
error   31-Mar-2016 14:15:50        at Object.<anonymous> (D:\Bamboo\bamboo-home\xml-data\build-dir\SON-FRON-JOB1\code\node_modules\del-cli\cli.js:30:1)
error   31-Mar-2016 14:15:50        at Module._compile (module.js:435:26)
error   31-Mar-2016 14:15:50        at Object.Module._extensions..js (module.js:442:10)

[BUG] <The library seems to not be safe with multiple webworkers>

What / Why

With reference with the following but sindresorhus/conf#102, it appears that in a multiple webworker environment the library may have problems.
I'm working inside an electron app.

What is happening when multiple webworkers try to write the same file:

  • Webworker 1 -> create tmp file
  • Webworker 2 -> create same tmp file (apparently the file name depends on the pid, which is the same from all the webworkers, at least in an electron environment)
  • Webworker 1 -> set file permission, write the file and delete it
  • Webworker 2 -> set file permission, but cannot since the file does not exists anymore. And throw an exception.

I'm getting the following exception:

ENOENT: no such file or directory, chown '/Users/oltreseba/Library/Preferences/project-nodejs/config.json.1638900804'

When

This happen when i try to write the same file from multiple webworkers. It may not happen always since it's related with multithreading.

Where

writeFileSync function. But probably writeFile has the same problem?

How

Current Behavior

The function throw an exception when attempting to write a not-exiting file.

Steps to Reproduce

Start multiple workers that write to the same file.

Expected Behavior

The file access should be piped probably?

Reporting a vulnerability

Hello!

I hope you are doing well!

We are a security research team. Our tool automatically detected a vulnerability in this repository. We want to disclose it responsibly. GitHub has a feature called Private vulnerability reporting, which enables security research to privately disclose a vulnerability. Unfortunately, it is not enabled for this repository.

Can you enable it, so that we can report it?

Thanks in advance!

PS: you can read about how to enable private vulnerability reporting here: https://docs.github.com/en/code-security/security-advisories/repository-security-advisories/configuring-private-vulnerability-reporting-for-a-repository

Module currently unusable in deno

Hey

I was trying to use firebase-admin in deno through jspm.io but module has a dependency from this library. write-file-atomic currently use worker_threads node api and its unusable in deno. It only take one function to get process pid so maybe it is possible add deno support for lib?

[BUG] The temporary file name is longer than the target file name

What / Why

This library creates a temp file by appending some hash to the target file name. This is bad because when the target file name is really long (but still inside the filesystem limit) the temp file name might get out of that limit and a ENAMETOOLONG error will happen

We started to have this issue in pnpm v5, where we have really long file names in the content-addressable storage.
Related issue: pnpm/pnpm#2605

How

Current Behavior

The temp file name is the <target file>.<hash>

Steps to Reproduce

Write a file that has a name 1 character shorter than the accepted limit.

Expected Behavior

The temp file name is short or at least not longer than the target file name.

References

pnpm/pnpm#2605

Make the temp file hidden

Currently, it creates a foo.ext.2343523 temp file of foo.ext. When doing an atomic file write in a folder the user might have open in Finder, they will see it and wonder what's happening. It would be nicer if the name of the temp file was prefixed with a ., so it would be invisible to the user.

Worker_threads console error

I get the following error in console and it won't let me continue.

script.js: 1 Error: Cannot find module 'worker_threads' from '/ home / freddy / projects / imageconvert / node_modules / npm / node_modules / write-file-atomic'

I am working with the latest version 3.0.3, because the version that comes with npm 2.6 also gives me the same error.

How could I solve this?

Thanks a lot

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.