Repository files navigation

graceful-fs functions as a drop-in replacement for the fs module,making various improvements.

The improvements are meant to normalize behavior across differentplatforms and environments, and to make filesystem access moreresilient to errors.

• Queues upopen andreaddir calls, and retries them oncesomething closes if there is an EMFILE error from too many filedescriptors.
• fixeslchmod for Node versions prior to 0.6.2.
• implementsfs.lutimes if possible. Otherwise it becomes a noop.
• ignoresEINVAL andEPERM errors inchown,fchown orlchown if the user isn't root.
• makeslchmod andlchown become noops, if not available.
• retries reading a file ifread results in EAGAIN error.

On Windows, it retries renaming a file for up to one second ifEACCESSorEPERM error occurs, likely because antivirus software has lockedthe directory.

// use just like fsvarfs=require('graceful-fs')// now go and do stuff with it...fs.readFile('some-file-or-whatever',(err,data)=>{// Do stuff here.})

This module cannot intercept or handleEMFILE orENFILE errors from syncmethods. If you use sync methods which open file descriptors then you areresponsible for dealing with any errors.

This is a known limitation, not a bug.

If you want to patch the global fs module (or any other fs-likemodule) you can do this:

// Make sure to read the caveat below.varrealFs=require('fs')vargracefulFs=require('graceful-fs')gracefulFs.gracefulify(realFs)

This should only ever be done at the top-level application layer, inorder to delay on EMFILE errors from any fs-using dependencies. Youshouldnot do this in a library, because it can cause unexpecteddelays in other parts of the program.

This module is fairly stable at this point, and used by a lot ofthings. That being said, because it implements a subtle behaviorchange in a core part of the node API, even modest changes can beextremely breaking, and the versioning is thus biased towardsbumping the major when in doubt.

The main change between major versions has been switching betweenproviding a fully-patchedfs module vs monkey-patching the node corebuiltin, and the approach by which a non-monkey-patchedfs wascreated.

The goal is to tradeEMFILE errors for slower fs operations. So, ifyou try to open a zillion files, rather than crashing,openoperations will be queued up and wait for something else toclose.

There are advantages to each approach. Monkey-patching the fs meansthat noEMFILE errors can possibly occur anywhere in yourapplication, because everything is using the same corefs module,which is patched. However, it can also obviously cause undesirableside-effects, especially if the module is loaded multiple times.

Implementing a separate-but-identical patchedfs module is moresurgical (and doesn't run the risk of patching multiple times), butalso imposes the challenge of keeping in sync with the core module.

The current approach loads thefs module, and then creates alookalike object that has all the same methods, except a few that arepatched. It is safe to use in all versions of Node from 0.8 through7.0.

• Do not monkey-patch the fs module. This module may now be used as adrop-in dep, and users can opt into monkey-patching the fs builtinif their app requires it.

• Monkey-patch fs, because the eval approach no longer works on recentnode.
• fixed possible type-error throw if rename fails on windows
• verify that wenever get EMFILE errors
• Ignore ENOSYS from chmod/chown
• clarify that graceful-fs must be used as a drop-in

• Use eval rather than monkey-patching fs.
• readdir: Always sort the results
• win32: requeue a file if error has an OK status

• A return to monkey patching
• wrap process.cwd

• 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
• Fixnpm/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

• Update engines for node 0.6
• Be lstat-graceful on Windows
• first