e94c184 should be reverted for the following reasons:

1. It makes policy decisions at too low a layer, where it has insufficient information. What if the embedder of libuv wants to know when a rename is blocked by antivirus?

2. It adds up to 1 second of latency through 4 retry attempts of 250ms each, instead of doing what the user expects it to do, i.e. issue a single rename instruction to the file system.

3. We already have retry logic baked into our application to handle antivirus interference. Should we now remove this?

4. This antivirus issue is not limited to rename but affects other fs calls too. Should libuv apply the same logic there too?

5. In any event, 4 retry attempts of 250ms is hardly sufficient. We have seen instances of Panda antivirus preventing renames for up to 2 seconds and longer.

6. This papering over only serves to make a fairly common event rarer, encouraging developers not to think about these things... until they happen, and they will, except now they will be much more surprising. It would be better to surface these errors and educate developers, rather than "hide them and surprise them".