fs: adjust truncate mode from r+ to a

[LiviaMedeiros]

This PR changes flags in fsPromises.truncate(path[, len]), fs.truncate(path[, len], callback), and fs.truncateSync(path[, len]) from r+ to a.

This change:

• Allows to truncate files without read permission (previously: EACCES)
• Allows to create a zero-filled file of specified length if it didn't exist at specified path

Creating file is not what pure truncate(2) does, but it is done by truncate(1) and kinda makes sense.

Alternatively, we can check for W_OK and throw ENOENT manually.

[aduh95]

/cc @nodejs/fs

[RaisinTen]

LGTM. Should we change r+ -> a in the docs too?

node/doc/api/fs.md

Line 586 in 71071f8

filehandle = await open('temp.txt', 'r+');

node/doc/api/fs.md

Line 2747 in 71071f8

open('temp.txt', 'r+', (err, fd) => {

[LiviaMedeiros]

Should we change r+ -> a in the docs too?

I don't think so. These examples are for filehandle.truncate(len) and fs.ftruncate(fd[, len], callback). Both methods are unaffected by this change, and both methods should be used in more complex scenarios. r+ effectively implies that filehandle or fd have untold adventures.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/44839/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/46489/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/46512/

There are a bunch of seemingly related CI failures on Windows.

[LiviaMedeiros]

node:internal/fs/utils:348
    throw err;
    ^

Error: EPERM: operation not permitted, ftruncate
    at Object.ftruncateSync (node:fs:1136:3)
    at Object.truncateSync (node:fs:1095:14)
    at Object.<anonymous> (C:\workspace\node-test-binary-windows-js-suites\node\test\parallel\test-fs-truncate.js:44:4)
    at Module._compile (node:internal/modules/cjs/loader:1129:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1183:10)
    at Module.load (node:internal/modules/cjs/loader:1007:32)
    at Module._load (node:internal/modules/cjs/loader:848:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:86:12)
    at node:internal/main/run_main_module:23:47 {
  errno: -4048,
  syscall: 'ftruncate',
  code: 'EPERM'
}

Node.js v19.0.0-pre

On a first glance, it looks like a bug in underlying layer. Most likely an attempt to allocate a sparse zero-filled range on a filesystem (probably FAT?) that doesn't support that.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/47144/

[aduh95]

Unfortunately, there are still failures on Windows, this will probably need to wait Node.js 20.0.0 if we are able to fix/workaround the failures.

[aduh95]

This PR has conflicts that must be resolved

[LiviaMedeiros]

Rebased, let's see if it still causes issues on Windows.
wip Issues and PRs that are still a work in progress. because the test has to be updated (assuming we can have this change)

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/65478/

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.26%. Comparing base (4ec9d42) to head (66f94ce).

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #43315      +/-   ##
==========================================
- Coverage   90.26%   90.26%   -0.01%     
==========================================
  Files         630      630              
  Lines      184690   184690              
  Branches    36157    36140      -17     
==========================================
- Hits       166718   166714       -4     
  Misses      11021    11021              
- Partials     6951     6955       +4     

Files with missing lines	Coverage Δ
lib/fs.js	98.25% <100.00%> (-0.03%)	⬇️
lib/internal/fs/promises.js	98.16% <100.00%> (-0.08%)	⬇️

... and 34 files with indirect coverage changes

[aduh95]

Getting Error: EPERM: operation not permitted, ftruncate on Windows CI