source: trip-planner-front/node_modules/graceful-fs/README.md@ e29cc2e

Last change on this file since e29cc2e was 6a3a178, checked in by Ema <ema_spirova@…>, 3 years ago

initial commit

  • Property mode set to 100644
File size: 4.6 KB
Line 
1# graceful-fs
2
3graceful-fs functions as a drop-in replacement for the fs module,
4making various improvements.
5
6The improvements are meant to normalize behavior across different
7platforms and environments, and to make filesystem access more
8resilient to errors.
9
10## Improvements over [fs module](https://nodejs.org/api/fs.html)
11
12* Queues up `open` and `readdir` calls, and retries them once
13 something closes if there is an EMFILE error from too many file
14 descriptors.
15* fixes `lchmod` for Node versions prior to 0.6.2.
16* implements `fs.lutimes` if possible. Otherwise it becomes a noop.
17* ignores `EINVAL` and `EPERM` errors in `chown`, `fchown` or
18 `lchown` if the user isn't root.
19* makes `lchmod` and `lchown` become noops, if not available.
20* retries reading a file if `read` results in EAGAIN error.
21
22On Windows, it retries renaming a file for up to one second if `EACCESS`
23or `EPERM` error occurs, likely because antivirus software has locked
24the directory.
25
26## USAGE
27
28```javascript
29// use just like fs
30var fs = require('graceful-fs')
31
32// now go and do stuff with it...
33fs.readFile('some-file-or-whatever', (err, data) => {
34 // Do stuff here.
35})
36```
37
38## Sync methods
39
40This module cannot intercept or handle `EMFILE` or `ENFILE` errors from sync
41methods. If you use sync methods which open file descriptors then you are
42responsible for dealing with any errors.
43
44This is a known limitation, not a bug.
45
46## Global Patching
47
48If you want to patch the global fs module (or any other fs-like
49module) you can do this:
50
51```javascript
52// Make sure to read the caveat below.
53var realFs = require('fs')
54var gracefulFs = require('graceful-fs')
55gracefulFs.gracefulify(realFs)
56```
57
58This should only ever be done at the top-level application layer, in
59order to delay on EMFILE errors from any fs-using dependencies. You
60should **not** do this in a library, because it can cause unexpected
61delays in other parts of the program.
62
63## Changes
64
65This module is fairly stable at this point, and used by a lot of
66things. That being said, because it implements a subtle behavior
67change in a core part of the node API, even modest changes can be
68extremely breaking, and the versioning is thus biased towards
69bumping the major when in doubt.
70
71The main change between major versions has been switching between
72providing a fully-patched `fs` module vs monkey-patching the node core
73builtin, and the approach by which a non-monkey-patched `fs` was
74created.
75
76The goal is to trade `EMFILE` errors for slower fs operations. So, if
77you try to open a zillion files, rather than crashing, `open`
78operations will be queued up and wait for something else to `close`.
79
80There are advantages to each approach. Monkey-patching the fs means
81that no `EMFILE` errors can possibly occur anywhere in your
82application, because everything is using the same core `fs` module,
83which is patched. However, it can also obviously cause undesirable
84side-effects, especially if the module is loaded multiple times.
85
86Implementing a separate-but-identical patched `fs` module is more
87surgical (and doesn't run the risk of patching multiple times), but
88also imposes the challenge of keeping in sync with the core module.
89
90The current approach loads the `fs` module, and then creates a
91lookalike object that has all the same methods, except a few that are
92patched. It is safe to use in all versions of Node from 0.8 through
937.0.
94
95### v4
96
97* Do not monkey-patch the fs module. This module may now be used as a
98 drop-in dep, and users can opt into monkey-patching the fs builtin
99 if their app requires it.
100
101### v3
102
103* Monkey-patch fs, because the eval approach no longer works on recent
104 node.
105* fixed possible type-error throw if rename fails on windows
106* verify that we *never* get EMFILE errors
107* Ignore ENOSYS from chmod/chown
108* clarify that graceful-fs must be used as a drop-in
109
110### v2.1.0
111
112* Use eval rather than monkey-patching fs.
113* readdir: Always sort the results
114* win32: requeue a file if error has an OK status
115
116### v2.0
117
118* A return to monkey patching
119* wrap process.cwd
120
121### v1.1
122
123* wrap readFile
124* Wrap fs.writeFile.
125* readdir protection
126* Don't clobber the fs builtin
127* Handle fs.read EAGAIN errors by trying again
128* Expose the curOpen counter
129* No-op lchown/lchmod if not implemented
130* fs.rename patch only for win32
131* Patch fs.rename to handle AV software on Windows
132* Close #4 Chown should not fail on einval or eperm if non-root
133* Fix isaacs/fstream#1 Only wrap fs one time
134* Fix #3 Start at 1024 max files, then back off on EMFILE
135* lutimes that doens't blow up on Linux
136* A full on-rewrite using a queue instead of just swallowing the EMFILE error
137* Wrap Read/Write streams as well
138
139### 1.0
140
141* Update engines for node 0.6
142* Be lstat-graceful on Windows
143* first
Note: See TracBrowser for help on using the repository browser.