[[chef-dev]] Re: [[chef-dev]] Re: [[chef-dev]] Re: [[chef-dev]] Re: [[chef-dev]]Re: [[chef-dev]]CHEF-1621-"recursive" attributeon "directory" resource does not apply users and groups to entire path

[Thomas Bishop < >]

> We can manage a tree of directories in fairly short order today using
> just a bit of surrounding Ruby:
>
>  top_dir = "/data/realtime"
>  ["", "fetched", "fetched/radar"].each do d
>    Directory "#{top_dir}/#{d}"
>       # stuff
>    end
>  end
>
> So any enhancement should feel easier and less confusing than that.
Agreed

>> 'recurse_down_from' makes sense to me for defining the starting point.
>>  It does however lead me to believe that it would equate to running
>> chmod/chown -R from that point.
>
> I guess I can see where you are coming from in terms of the chown -R,
> but am surprised that you would want to set permissions on files in a
> directory tree based on the permissions you want on the directory;
> directories generally need to be +x but that is not generally what you
> want for all the files.
>
> And chmod/chown -R is hard.  To implement this you either have to check
> permissions on every file contained in a directory tree or just go
> ahead and perform the operation on each run.  Either way is going to
> be expensive in terms of time for large and deep directory trees.
> While I can see how one might think of a Directory resource managining
> the files within a tree, I prefer the simplicity of the current
> setup: the Directory resource just manages the directory itself; think
> mkdir, not magicdir.
>
That makes sense.  I was thinking of a case when you would want to set
the attributes of all of the files in a directory.  I can see how the
majority of cases probably wouldn't want this behavior and it's
probably better served with an explicit definition.  I definitely
agree that chmod/chown -R like behavior is expensive (short of
shelling out).  I think some clarification in the documentation should
suffice for the non chmod/chown -R behavior for the entire tree.


On Thu, Oct 14, 2010 at 09:24, Seth Falcon 
<
 >
 wrote:
> On Wed, Oct 13, 2010 at 10:08 PM, Thomas Bishop 
> <
 >
>  wrote:
>> I'm wondering if that may cause confusion of when to use directory vs.
>> directory_tree.
>
> Yes, that's a downside.  I'm not 100% sold on the idea of creating a
> new resource.  I have a feeling that any enhancement is going to add
> complexity and the possibility of confusion.
>
> We can manage a tree of directories in fairly short order today using
> just a bit of surrounding Ruby:
>
>  top_dir = "/data/realtime"
>  ["", "fetched", "fetched/radar"].each do d
>    Directory "#{top_dir}/#{d}"
>       # stuff
>    end
>  end
>
> So any enhancement should feel easier and less confusing than that.
>
>> 'recurse_down_from' makes sense to me for defining the starting point.
>>  It does however lead me to believe that it would equate to running
>> chmod/chown -R from that point.
>
> I guess I can see where you are coming from in terms of the chown -R,
> but am surprised that you would want to set permissions on files in a
> directory tree based on the permissions you want on the directory;
> directories generally need to be +x but that is not generally what you
> want for all the files.
>
> And chmod/chown -R is hard.  To implement this you either have to check
> permissions on every file contained in a directory tree or just go
> ahead and perform the operation on each run.  Either way is going to
> be expensive in terms of time for large and deep directory trees.
> While I can see how one might think of a Directory resource managining
> the files within a tree, I prefer the simplicity of the current
> setup: the Directory resource just manages the directory itself; think
> mkdir, not magicdir.
>
>>  Perhaps adding another setting
>> (recurse_all_subcontent/children/entries?
>> include_subcontent/children/entries? other?) to denote that everything
>> in the tree will be set?
>
> If this is the desired behavior, perhaps this is best handled with an
> explicit execute resource doing the "chown -R".
>
>
> + seth
>