node-graceful-fs

graceful-fs graceful-fs 可作为 fs 模块的替代方案，并做出了各种改进。这些改进旨在使不同平台和环境的行为标准化，并使文件系统访问更具抵御错误的能力。与 fs 模块相比的改进 将打开和 readdir 调用排队，并在出现 EMFILE 错误（由于文件描述符过多）时重试一次。修复了 Node 0.6.2 之前版本的 lchmod。如果可能，实现 fs.lutimes。否则，它将成为一个 noop。在 chown、fchown 或 lchown 中忽略 EINVAL 和 EPERM 错误，如果用户不是 root。使 lchmod 和 lchown 成为 noop，如果不存在。如果读取文件时出现 EAGAIN 错误，则重试。在 Windows 上，如果出现 EACCESS 或 EPERM 错误，则重试重命名文件，最多一秒钟。这可能是因为防病毒软件锁定了目录。 使用 JavaScript // 使用与 fs 相同 var fs = require('graceful-fs') // 现在去做与它有关的事情... fs.readFile('some-file-or-whatever', (err, data) = { // 在此处做事情 }) 同步方法 此模块无法拦截或处理来自同步方法的 EMFILE 或 ENFILE 错误。如果使用打开文件描述符的同步方法，则您负责处理任何错误。这是一个已知的限制，而不是一个 bug。 全局补丁 如果您想对全局 fs 模块（或任何其他类似于 fs 的模块）进行补丁，可以这样做： JavaScript // 请务必阅读下面的警告。 var realFs = require('fs') var gracefulFs = require('graceful-fs') gracefulFs.gracefulify(realFs) 这只能在顶层应用程序层中进行，以延迟来自任何使用 fs 的依赖项的 EMFILE 错误。您不应在库中这样做，因为这可能会导致程序其他部分出现意外延迟。 变更 此模块目前相当稳定，并被许多东西使用。尽管如此，由于它在 node API 的核心部分实现了一个微妙的行为变化，即使是微小的变化也可能极其破坏性，因此版本号偏向于在怀疑时升级主版本。主版本之间的主要变化是切换提供完全补丁后的 fs 模块与使用 monkey-patch 的…