Generating tsd.json changes its parent directory's permission to 0744

[ooxif]

tsd init -o, tsd reinstall -s (and other) changes its parent directory's permission to 0744 (which I don't want to).

Why xm.file.mkdirCheckQ() (or xm.fileIO.mkdirCheck()) changes the permission to 0744 statically even though the directory is writable (0700, 0755, 0775, 0777, ...)?

[Bartvds]

No particular reason; I'm a windows guy myself so I know not much about this so your advice would be welcome.

I see in the mkdirp readme it uses this as default:

0777 & (~process.umask()).

Would that solve your issue?

[Bartvds]

@ooxif I'm moving to release 0.6 soon, so if you want this fixed some advice would be welcome.

[Bartvds]

@ooxif last chance before I push 0.6

[Callmenorm]

I'm also seeing this issue on Fedora 22. My default process umask is 0002, but the parent directory, which already exists, is being changed to 744. If mkdirp was behaving correctly I wouldn't expect the permissions on directories that already exist to be changed at all. If mkdirp is changing the permissions then the permissions should still have execute permissions since the umask of 0002 only gets rid of write permissions.

The main problem is that the execute permissions for group and other are being removed, so non-owners can't cd to the directory.

[nahuel]

Electron seems to refuse to load resouces from .asar files when the parent directory has 0744 permissions, so doing a "tsd init" can break electron based projects in a very subtle way.

[dimkir]

I have tsd 0.6.5 installed on ubuntu via npm install tsd and the problem still persists.

My directory permissions are reset to 744 when running tsd init...

[PowerKiKi]

Same here. 775 would be a much saner default IMHO, letting group also read and write. But I guess since the project is deprecated we are out of luck...