directory resource won't set permissions or ownership recursively

The issue here is that the "recursive" property is implemented to mean something like "make_parents", corresponding to "mkdir -p".

I will make that functionality respond to a "make_parents" property and implement "recursive" to recursively apply perms and ownership to the earliest component of the directory that does not already exist or the specified directory if they all do.

For example, if the directory /foo exists and directory resource for "/foo/bar/baz" has action :create and recursive true, /foo/bar and /foo/bar/baz will be created with the specified properties.

The following is a table that represents how the recursive attribute should affect the system based on the initial state:

Initial state-dirs that exist and not owned by user | "create recursive" called on | Dirs user now owns
----------------------------------------------------------------|------------------------------------|--------------------------
/ | /p/c/g | /p, /p/c, /p/c/g
/p | /p/c/g | /p/c, /p/c/g
/p/c | /p/c/g | /p/c/g
/p/c/g | /p/c/g | /p/c/g
/p/c/g | /p/c | /p/c, /p/c/g

Ping, CW? how's this looking?

I'm not sure this actually a good idea - for large directories, this will be very expensive - and the cost of breaking out to the shell at this point is way lower.

I'm triaging this, but i'm not sure we should ship anything that fixes this bug.

I can see how this is difficult to fix, given the semantics of the directory resource, but can the documentation at least be improved to make it clear that any permissions that might be applied apply to the "leaf" directories only, not any directories that might be created as a consequence of the recursive setting? This "bug" has got me a few times.

Even though this is much older, I'm going to close this as a duplicate of CHEF-1621. There's a good link there to an extensive mailing list discussion on this subject.