You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

README.md 4.3KB

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