Installations
npm install graceful-fs
Score
98.1
Supply Chain
99.5
Quality
75.9
Maintenance
100
Vulnerability
100
License
Releases
Unable to fetch releases
Developer
isaacs
Developer Guide
Module System
CommonJS
Min. Node Version
Typescript Support
No
Node Version
18.14.0
NPM Version
9.5.1
Statistics
1,273 Stars
230 Commits
148 Forks
26 Watching
22 Branches
29 Contributors
Updated on 23 Nov 2024
Bundle Size
10.80 kB
Minified
3.42 kB
Minified + Gzipped
Languages
JavaScript (100%)
Total Downloads
Cumulative downloads
Total Downloads
12,660,966,555
Last day
-7.3%
12,348,778
Compared to previous day
Last week
2.7%
73,739,483
Compared to previous week
Last month
17.4%
293,065,982
Compared to previous month
Last year
10.5%
2,889,591,907
Compared to previous year
Daily Downloads
Weekly Downloads
Monthly Downloads
Yearly Downloads
Dev Dependencies
4
graceful-fs
graceful-fs functions as a drop-in replacement for the fs module, making various improvements.
The improvements are meant to normalize behavior across different platforms and environments, and to make filesystem access more resilient to errors.
Improvements over fs module
- Queues up
open
andreaddir
calls, and retries them once something closes if there is an EMFILE error from too many file descriptors. - fixes
lchmod
for Node versions prior to 0.6.2. - implements
fs.lutimes
if possible. Otherwise it becomes a noop. - ignores
EINVAL
andEPERM
errors inchown
,fchown
orlchown
if the user isn't root. - makes
lchmod
andlchown
become noops, if not available. - retries reading a file if
read
results in EAGAIN error.
On Windows, it retries renaming a file for up to one second if EACCESS
or EPERM
error occurs, likely because antivirus software has locked
the directory.
USAGE
1// use just like fs 2var fs = require('graceful-fs') 3 4// now go and do stuff with it... 5fs.readFile('some-file-or-whatever', (err, data) => { 6 // Do stuff here. 7})
Sync methods
This module cannot intercept or handle EMFILE
or ENFILE
errors from sync
methods. If you use sync methods which open file descriptors then you are
responsible for dealing with any errors.
This is a known limitation, not a bug.
Global Patching
If you want to patch the global fs module (or any other fs-like module) you can do this:
1// Make sure to read the caveat below. 2var realFs = require('fs') 3var gracefulFs = require('graceful-fs') 4gracefulFs.gracefulify(realFs)
This should only ever be done at the top-level application layer, in order to delay on EMFILE errors from any fs-using dependencies. You should not do this in a library, because it can cause unexpected delays in other parts of the program.
Changes
This module is fairly stable at this point, and used by a lot of things. That being said, because it implements a subtle behavior change in a core part of the node API, even modest changes can be extremely breaking, and the versioning is thus biased towards bumping the major when in doubt.
The main change between major versions has been switching between
providing a fully-patched fs
module vs monkey-patching the node core
builtin, and the approach by which a non-monkey-patched fs
was
created.
The goal is to trade EMFILE
errors for slower fs operations. So, if
you try to open a zillion files, rather than crashing, open
operations will be queued up and wait for something else to close
.
There are advantages to each approach. Monkey-patching the fs means
that no EMFILE
errors can possibly occur anywhere in your
application, because everything is using the same core fs
module,
which is patched. However, it can also obviously cause undesirable
side-effects, especially if the module is loaded multiple times.
Implementing a separate-but-identical patched fs
module is more
surgical (and doesn't run the risk of patching multiple times), but
also imposes the challenge of keeping in sync with the core module.
The current approach loads the fs
module, and then creates a
lookalike object that has all the same methods, except a few that are
patched. It is safe to use in all versions of Node from 0.8 through
7.0.
v4
- Do not monkey-patch the fs module. This module may now be used as a drop-in dep, and users can opt into monkey-patching the fs builtin if their app requires it.
v3
- Monkey-patch fs, because the eval approach no longer works on recent node.
- fixed possible type-error throw if rename fails on windows
- verify that we never get EMFILE errors
- Ignore ENOSYS from chmod/chown
- clarify that graceful-fs must be used as a drop-in
v2.1.0
- Use eval rather than monkey-patching fs.
- readdir: Always sort the results
- win32: requeue a file if error has an OK status
v2.0
- A return to monkey patching
- wrap process.cwd
v1.1
- wrap readFile
- Wrap fs.writeFile.
- readdir protection
- Don't clobber the fs builtin
- Handle fs.read EAGAIN errors by trying again
- Expose the curOpen counter
- No-op lchown/lchmod if not implemented
- fs.rename patch only for win32
- Patch fs.rename to handle AV software on Windows
- Close #4 Chown should not fail on einval or eperm if non-root
- Fix isaacs/fstream#1 Only wrap fs one time
- Fix #3 Start at 1024 max files, then back off on EMFILE
- lutimes that doens't blow up on Linux
- A full on-rewrite using a queue instead of just swallowing the EMFILE error
- Wrap Read/Write streams as well
1.0
- Update engines for node 0.6
- Be lstat-graceful on Windows
- first
No vulnerabilities found.
Reason
no dangerous workflow patterns detected
Reason
no binaries found in the repo
Reason
license file detected
Details
- Info: project has a license file: LICENSE:0
- Info: FSF or OSI recognized license: ISC License: LICENSE:0
Reason
7 existing vulnerabilities detected
Details
- Warn: Project is vulnerable to: GHSA-67hx-6x53-jw92
- Warn: Project is vulnerable to: GHSA-grv7-fg5c-xmjg
- Warn: Project is vulnerable to: GHSA-3xgq-45jj-v275
- Warn: Project is vulnerable to: GHSA-vh95-rmgr-6w4m / GHSA-xvch-5gv4-984h
- Warn: Project is vulnerable to: GHSA-rxrc-rgv4-jpvx
- Warn: Project is vulnerable to: GHSA-c2qf-rxjj-qqgw
- Warn: Project is vulnerable to: GHSA-3h5v-q93c-6h6q
Reason
Found 2/30 approved changesets -- score normalized to 0
Reason
detected GitHub workflow tokens with excessive permissions
Details
- Warn: no topLevel permission defined: .github/workflows/ci.yml:1
- Warn: no topLevel permission defined: .github/workflows/isaacs-makework.yml:1
- Info: no jobLevel write permissions found
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
- Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/ci.yml:17: update your workflow using https://app.stepsecurity.io/secureworkflow/isaacs/node-graceful-fs/ci.yml/main?enable=pin
- Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/ci.yml:20: update your workflow using https://app.stepsecurity.io/secureworkflow/isaacs/node-graceful-fs/ci.yml/main?enable=pin
- Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/isaacs-makework.yml:13: update your workflow using https://app.stepsecurity.io/secureworkflow/isaacs/node-graceful-fs/isaacs-makework.yml/main?enable=pin
- Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/isaacs-makework.yml:17: update your workflow using https://app.stepsecurity.io/secureworkflow/isaacs/node-graceful-fs/isaacs-makework.yml/main?enable=pin
- Warn: npmCommand not pinned by hash: .github/workflows/ci.yml:26
- Info: 0 out of 4 GitHub-owned GitHubAction dependencies pinned
- Info: 0 out of 1 npmCommand dependencies pinned
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
project is not fuzzed
Details
- Warn: no fuzzer integrations found
Reason
branch protection not enabled on development/release branches
Details
- Warn: branch protection not enabled for branch 'main'
Reason
security policy file not detected
Details
- Warn: no security policy file detected
- Warn: no security file to analyze
- Warn: no security file to analyze
- Warn: no security file to analyze
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
- Warn: 0 commits out of 2 are checked with a SAST tool
Score
2.8
/10
Last Scanned on 2024-11-25
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More