Inconsistent error codes across platforms when writing to read-only (444) files

[pitaj]

• Version: 8.8.1
• Platform: tested on these systems
  • Linux peter-XPS-15 4.13.0-16-generic #19-Ubuntu SMP Wed Oct 11 18:35:14 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
  • Windows 10 64bit (version 1709)
• Subsystem: fs

Attempting to write to a read-only file will result in:

• an EACCES error on Linux systems
• an EPERM error on Windows systems

Is this expected behavior? If so, it should be documented as such. The only mention of EPERM is with relation to hidden files.

You can reproduce this by executing the following snippet on machines of the two different platforms.

const fs = require('fs');
const path = require('path');

const code = '444';
const filename = '00000';
const content = 'abcdefghijklmnopqrstuvwxyz';
const filePath = path.join(__dirname, filename);

// set up a read-only file
fs.writeFileSync(filePath, content);
fs.chmodSync(filePath, '444');

fs.writeFile(filePath, content, function (err) {
  throw err;
});

https://gist.github.com/pitaj/047faae18463835a8b7697e2964a341e

[gireeshpunathil]

In Linux and MAC where I tested, I see no issues with the error - it is just a reflection of the low level error came from the system, and it is prudent to keep them as such for clarity and ease on diagnosis.

#ls -lrt 00000
-r--r--r--  1 gireesh  staff  26 Oct 30 12:15 00000
#cat w.c

#include <stdio.h>
#include <fcntl.h>
#include <errno.h>
#include <stdlib.h>

int main() {
  int fd = open("./00000", O_RDWR);
  if(fd == -1) {
    fprintf(stderr, "error: %d\n", errno);
    exit(1);
  }
}

#cc w.c
#./a.out
error: 13
#

And this perfectly makes sense:
#define EACCES 13 /* Permission denied */

In windows also I see EACCES is present and better represent the error at hand, however, looks like it took a different route and ended up in EPERM.

/cc @nodejs/platform-windows

[pitaj]

Just to clarify, I don't see any issues with the error codes currently used, the only problem I have is that they are inconsistent between Linux and Windows.

[gireeshpunathil]

sure, but I see an issue with EPERM . Excerpts from Windows manual:

EACCES
Permission denied. The file's permission setting does not allow the specified access. This error signifies that an attempt was made to access a file (or, in some cases, a directory) in a way that is incompatible with the file's attributes.

#define EPERM [operation not permitted]  

So for the current context, EACCES is the most apt one. So it is worth looking into it to see whether EPERM is coming from Win32 system itself, or from some wrappers, and in either case, the rational of doing so.

[gireeshpunathil]

and, that may probably also lead to an answer why this disparity

[seishun]

PR to fix this: libuv/libuv#1612

[seishun]

Why was this autoclosed?

[addaleax]

@seishun GitHub does that when a commit with a Fixes: tag lands in the main branch of a repo and the commiter has write access to the repo to which the issue refers (the commit doesn’t have to be in the same repo as the bug)

[gireeshpunathil]

@seishun - should this remain open?

[seishun]

This should remain open until libuv is upgraded to 2.x.

[jasnell]

Given that it's not clear if and when (if ever) libuv will move to 2.x, and given that there's been zero activity on this in over 2 years, I recommend closing as there's no action we can reasonably take here.

[santigimeno]

Already fixed:

• deps: upgrade to libuv 1.43.0 #41398
• Correct the error type of fs.writeFile with read-only mode #38607