GeezerVison is showing github.com — Inconsistent error codes across platforms when writing to read-only (444) files · Issue #16596 · nodejs/node
Inconsistent error codes across platforms when writing to read-only (444) files #16596Description
- 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 Activitygireeshpunathil commented on Oct 30, 2017 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 commented on Oct 30, 2017 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 commented on Oct 30, 2017 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 commented on Oct 30, 2017 and, that may probably also lead to an answer why this disparity seishun commented on Oct 31, 2017 Reacted by Gireesh Punathil seishun commented on Feb 27, 2018 addaleax commented on Feb 27, 2018 @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) Reacted by Benjamin Gruenbaum gireeshpunathil commented on Mar 30, 2018 seishun commented on Mar 30, 2018 This should remain open until libuv is upgraded to 2.x. jasnell commented on Jun 19, 2020 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 commented on Nov 14, 2022
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|
