rmSync does not throw error if file exists but cannot be deleted.

[rhwood]

• Version: v14.17.0 and v16.1.0
• Platform: Darwin Randalls-iMac.fios-router.home 20.4.0 Darwin Kernel Version 20.4.0: Thu Apr 22 21:46:47 PDT 2021; root:xnu-7195.101.2~1/RELEASE_X86_64 x86_64 (macOS 11.3.1)
• Subsystem: filesystem

What steps will reproduce the bug?

fs.rmSync does not error if file exists, but cannot be deleted because parent directory is readonly. The file remains, but no error is thrown. (Note that fs.rm works as expected.)

I expect the following code to emit an EACCES error, but it does not:

import * as nodefs from 'fs'

nodefs.mkdirSync('tmp')
nodefs.writeFileSync('tmp/file', 'A file.')
nodefs.chmodSync('tmp', '500')
nodefs.rmSync('tmp/file' {force: true})

However, this code does emit that error:

import * as nodefs from 'fs'

nodefs.mkdirSync('tmp')
nodefs.writeFileSync('tmp/file', 'A file.')
nodefs.chmodSync('tmp', '500')
nodefs.rm('tmp/file', {force: true}, function(err) {
    if (err) console.error(err)
})

as does:

import * as nodefs from 'fs'
import * as promisefs from 'fs/promises'

nodefs.mkdirSync('tmp')
nodefs.writeFileSync('tmp/file', 'A file.')
nodefs.chmodSync('tmp', '500')
promisefs.rm('tmp/file', {force: true})

How often does it reproduce? Is there a required condition?

Always reproducible.

What is the expected behavior?

The file is not deleted, and the error is emitted:

[Error: EACCES: permission denied, unlink 'tmp/file'] {
  errno: -13,
  code: 'EACCES',
  syscall: 'unlink',
  path: 'tmp/file'
}

What do you see instead?

The file is not deleted, but no error is emitted.

Additional information

The commands mkdir tmp ; touch tmp/file ; chmod 500 tmp ; rm -f tmp/file show the expected result rm: tmp/file: Permission denied and the file is not deleted.

I believe Linux systems also exhibit this, but have not explicitly tested this minimal reproducible example on Linux.

[Linkgoron]

I think I've found the issue, I'll take a look

[babatakao]

Hi, thank you for the fix. Any plan to backport to 16.x LTS?

[rhwood]

@babatakao I understand fixing this caused so many unexpected failures revealed so many uses that needed to catch errors in their CI environment that fixing this is considered a breaking change.

[Linkgoron]

Fixing this issue kind of broke Node.js's build, so we assumed that others would probably face similar issues.

[babatakao]

I understand. Thanks!