You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was seeing this on my Mac despite I thought having a test to make sure "reasonable" default permissions were used. Evidently the full permission bits need to be passed and then they are still masked with umask.
What I'm currently using which seems to work:
// TODO: correct default permissions here? should it include group/world?
uv_fs_mkdir(getLoop(), request, path, S_IRWXU, fileDirectoryCallback);
This might be too limited though... Perhaps we should just default to 777 and then let umask do it's thing? That seems to be the behavior when I create a directory from the shell itself.
The text was updated successfully, but these errors were encountered:
joshgoebel
changed the title
Directory defaulting to mode 0 results in having no permissions
IO: Directory.create defaulting mode 0 results in no permissions
May 30, 2021
Now that Wren-cli version 0.4.0 has been officially released, I was just testing Directory.create myself (on Ubuntu 20.04) and I think we should set the permissions (i.e. the mode parameter in uv_fs_mkdir) to octal 0755 (decimal 493).
That will give read and execute access for everyone and write access for the directory owner (drwxr-xr-x) which is what you normally get with mkdir under Linux. It may also suffice for MacOS (sorry I don't use it).
However, the libuv docs say that the mode parameter isn't currently implemented on Windows so I don't know what we can do there unless we can set them after the directory has been created.
I was seeing this on my Mac despite I thought having a test to make sure "reasonable" default permissions were used. Evidently the full permission bits need to be passed and then they are still masked with
umask
.What I'm currently using which seems to work:
This might be too limited though... Perhaps we should just default to 777 and then let umask do it's thing? That seems to be the behavior when I create a directory from the shell itself.
The text was updated successfully, but these errors were encountered: