On Wednesday, June 22, 2011 at 11:50 PM, Aseem Kishore wrote:
> Sorry if I'm overlooking something really basic, but why won't this work on my MacBook running Snow Leopard?
fs.mkdir and mkdirSync take another argument: the permission mode. 'undefined' is not a valid argument for that.
----
Aria Stewart
--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
The system library call that fs.mkdir is based on requires the mode.
(See http://linux.die.net/man/2/mkdir) It's the shell command that
provides a default for you.
\m/
I'd use 0700 which means that you can do everything and everyone else
can do nothing. 0700 is base 8, so you need to preserve the leading
zero.
On Thursday, June 23, 2011 at 2:32 PM, Aseem Kishore wrote:
> So as a Unix noob, what mode is recommended to pass here for making regular, simple read/write directories? Or, how do I determine such a mode?
>
> (I've done a bunch of searching and reading up on man pages, so this question is not for lack of trying! Just wondering what people recommend.)
>
> When I call `fs.stat` on any directory in my project repos, they all return mode 16877, which I have yet to figure out how to deconstruct to the meaningful info that stat(2) describes for modes. (E.g. it says 0040000 means directory, but 16877 is < 40000. Am I assuming wrong when I assume bit flags are added?)
>
> But I've noticed some code uses 0755 as a mode for directories. What does that mean, and to add to the confusion, how does that convey a directory?
The biggest thing to know is that the numbers led with 0 are octal. That said, Javascript only supports hex and decimal, so you're gonna be surprised by that if you use it verbatim. `0755` is `493` decimal.
> And related to this, it also seems there's no automatic "-p" equivalent -- to make intermediate directories automatically. I found this by Isaac:
>
> https://github.com/isaacs/npm/blob/master/lib/utils/mkdir-p.js
Indeed: So use that, or copy it in. Node's mkdir is mkdir(2), the system call, not mkdir(1), the shell command.
> But man that's a lot of boilerplate code I would hate to reproduce. In this case, I also can't simply require() npm to get it; this is async, and I need sync as I need to create a directory during require() time, which is sync.
You might split your code to take a callback and tell the system when it's done. `require('yourmodule').init(function(err) { .... })`
> I found an old thread from March 2010 where somebody said they submitted a patch for `fs.mkdirs()`, but I don't see it in today's Node:
>
> http://comments.gmane.org/gmane.comp.lang.javascript.nodejs/3307
>
> May I toss in my two cents that it would be awesome if the core fs module were a lot more user-friendly and had reasonable defaults and these convenience helpers so that every Node.js script author didn't have to reinvent the wheel?
I heartily endorse this -- though I'd love to see it stay low-level. Sane defaults if there are some (not sure there are for the mode -- what you want is going to depend on how private you want to make the files, and whether your OS uses usergroups or not.)
Some symbolic constants might make sense. `mode.USERREAD | mode.GROUPREAD | mode.USERWRITE`
The thing to watch out with a `mkdir -p` equivalent is that you have an error possibility at each step of the chain, and you may well want to get access to which part failed. That's a much more complex API on the error handling side, hence rolling your own.
----
Aria Stewart
I assume you know and understand that the umask is not the file
permissions but is *applied* to the file permissions (think: mode &=
~umask) and that mkdir(2) applies it anyway, no need to call
getumask(3) (which is a non-portable GNU-ism and not implemented in
all versions of glibc).
Anyway, explicit is better than implicit so I vote against a default
mode. Added plus: prevents flame wars about what default is best.
Huh, what?
$ node
> 0x10
16
> 010
8
> 10
10
$ node -v
v0.4.9-pre
Okay, wow. I must have totally botched that up when I double-checked. Maybe I'm thinking of strict mode and just blew my own testing.
So sorry about that!
Octal support using a leading zero was dropped for ECMAScript 5 strict mode.
On Thu, Jun 23, 2011 at 20:51, Matt <hel...@gmail.com> wrote:I assume you know and understand that the umask is not the file
> To be fair, there's no reason mkdir couldn't call getumask(3).
permissions but is *applied* to the file permissions (think: mode &=
~umask) and that mkdir(2) applies it anyway
I keep meaning to split that out into a separate module like I did
with rimraf. It should be very extractable.
The blocking issue, as with rimraf, is that npm actually has a need
for a pretty fancy "make a bunch of directories" utility, quite above
and beyond what mkdir(1) implements. It also sets ownership, and
mode, and can default the ownership/mode to that of the closest
existing parent, and so on. While it would probably be handy to put
all these features in a standalone mkdir util, I haven't come up with
a nice API for it, so it remains buried in npm's guts.
With rimraf, I just stripped out all the fancier features from npm's
rm-rf.js module, which is tweaked to tell you which things could not
be removed on process exit, so that you can clean up manually if
necessary. I'm not super happy with this; it would be better to have
npm use the "actual" rimraf module, and extend rimraf to do what npm
needs. If it's not meeting my needs, then it's probably also not
meeting someone else's.
Re: fs.is{Read,Writ,Execut}able{,Sync}(path[, cb])
Planned. Not yet done. Will be in 0.5.
https://github.com/joyent/node/issues/879
Here's some code to use for now: https://gist.github.com/841992
All of node's fs functions that take integers to specify modes also
take octal strings. So, for example, fs.mkdir(somePath, "0755", cb)
is fine.
--
Re: npm's mkdir-p
I keep meaning to split that out into a separate module like I did
with rimraf. It should be very extractable.