The recursive rmdir() currently supports two options:
emfileWait - When EMFILE (and soon ENFILE) is encountered, the operation is retried. The retry logic involves creating a series of timers, where the delay increases by 1ms until emfileWait is reached. This is only used in the asynchronous rimraf, and once it supports ENFILE, the name isn't really accurate anymore. This currently defaults to 1000.maxBusyTries - This option is used when EBUSY, ENOTEMPTY, or EPERM is encountered. This retry logic involves creating a series of maxBusyTries timers, where the delay increases by 100ms. This is also only used in the asynchronous rimraf. This currently defaults to 3.
I'm proposing the following changes (note that rimraf is still experimental):
- Rename
maxBusyTries to maxRetries and make the default 0. By making the default 0, I think we can start applying this to the synchronous rimraf. I think retries should be opt-in, particularly for synchronous operations, which can block the event loop for a while. I also think that the async and sync versions should have consistent handling of retry logic.
- Remove
emfileWait completely, and use the same retry logic consistently.
- Introduce a
retryDelay option that specifies the amount of time to wait between retry attempts.
The recursive
rmdir()currently supports two options:emfileWait- WhenEMFILE(and soonENFILE) is encountered, the operation is retried. The retry logic involves creating a series of timers, where the delay increases by 1ms untilemfileWaitis reached. This is only used in the asynchronous rimraf, and once it supportsENFILE, the name isn't really accurate anymore. This currently defaults to 1000.maxBusyTries- This option is used whenEBUSY,ENOTEMPTY, orEPERMis encountered. This retry logic involves creating a series ofmaxBusyTriestimers, where the delay increases by 100ms. This is also only used in the asynchronous rimraf. This currently defaults to 3.I'm proposing the following changes (note that rimraf is still experimental):
maxBusyTriestomaxRetriesand make the default 0. By making the default 0, I think we can start applying this to the synchronous rimraf. I think retries should be opt-in, particularly for synchronous operations, which can block the event loop for a while. I also think that the async and sync versions should have consistent handling of retry logic.emfileWaitcompletely, and use the same retry logic consistently.retryDelayoption that specifies the amount of time to wait between retry attempts.