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

[Thomas Bishop < >]

I see your perspective in the case of a new directory.

Given the user's example, my initial expectation is that I would have
to do the following:

directory "/data/realtime/fetched/radar" do
  action :create
  owner "ldm"
  group "ldm"
  mode "777"
end

directory "/data" do
  action :create
  owner "ldm"
  group "ldm"
  mode "777"
  recursive true
end

To me, this is more clear of what should happen.  I think there are a
couple of items that lead me to this.

1.  I'm probably influenced by how I would do this on the command
line. (mkdir -p /data/realtime/fetched/radar; chmod -R 777 /data;
chown -R ldm:ldm /data;)

2.  When I see 'recursive', I think of impacting down the tree of the
argument specified and not up.  Again, probably influenced by the
behavior of command line tools (cp -R, chmod -R, chown -R, etc.).


I guess another approach could be to have an attribute which denotes
to apply the ownership/permission settings to the entire path or
perhaps at a specific starting part.  Although this could be confusing
as well in combination with the recursive attribute.  Maybe change the
recursive attribute from a boolean to fit this type of functionality?
I don't care for either of these approaches too much.


I think this might just be a preference of implicit vs. explicit.

Personally, for something like file system
hierarchies/ownership/permissions I would prefer explicit definition.


Thoughts?


-Tommy


On Sat, Oct 2, 2010 at 19:02, Chad Woolley 
<
 >
 wrote:
> On Sat, Oct 2, 2010 at 4:22 PM, Thomas Bishop 
> <
 >
>  wrote:
>> Hi folks,
>>
>> I was discussing this ticket with Dan DeLeo on irc and we thought it
>> would be a good idea to get feedback from a larger audience.
>>
>> Have a look at the example at http://tickets.opscode.com/browse/CHEF-1621.
>>
>> The user was expecting:
>>
>> 777 ldm:ldm /data
>> 777 ldm:ldm /data/realtime
>> 777 ldm:ldm /data/realtime/fetched
>> 777 ldm:ldm /data/realtime/fetched/radar
>>
>>
>> Here's what chef did:
>>
>> 755 root:root /data
>> 755 root:root /data/realtime
>> 755 root:root /data/realtime/fetched
>> 777 ldm:ldm /data/realtime/fetched/radar
>>
>>
>> The current chef behavior makes sense to me.  Here are a couple of reasons 
>> why:
>>
>> 1.  As the directory being defined is /data/realtime/fetched/radar, I
>> would not expect chef to touch the ownership or permissions on
>> anything above it.  I would however expect chef to create the required
>> parent directories if they did not exist in order to satisfy the
>> desired state.
>>
>> 2.  If chef modified the permissions/ownership for the entire
>> structure, this could have adverse effects if there were additional
>> directories defined under /data, or /data/realtime or
>> /data/realtime/fetched.  If /data/foo existed for example.  In my
>> opinion, this would be counterintuitive behavior.
>>
>>
>> I agree with the ticket submitter that the docs aren't 100% clear on
>> this and should probably be updated.
>>
>>
>> I would love to hear additional thoughts on this.
>
> That makes sense, if the tree already exists.  You don't want to muck
> with existing permissions.
>
> However, if the parent directory hierarchy were being created from
> scratch (did not already exist), what should happen?  Should they be
> owned by root, or by the owner of the file at the bottom of the
> hierarchy?
>
> I think the latter makes sense, otherwise you'd have to explicitly
> create every level in the hierarchy and assign permissions.  That'd be
> silly.
>
> -- Chad
>