" But if I subsequently call file again and just specify the entry point to my tree"
I would hope the module didn't act differently on subsequent runs. Not sure what I want resolution to be, but filing a bug there is worthwhile. On Tue, Jul 29, 2014 at 7:16 PM, Michael DeHaan <[email protected]> wrote: > Recursive directory setting is almost never something you want to do. > > Assume "/foo/bar" doesn't exist and the directory specified is > "/foo/bar/baz/gulp/gorp" > > The permissions on the leaf node may be good choices, but what should the > intermediate permissions be set as? Do they come from bar or gorp?" > > As such, when doing recursive copying, setting permissions on each leaf > node makes sense. > > Otherwise, just call chmod -R, and it will do what it normally does. > > > > > On Tue, Jul 29, 2014 at 6:23 PM, <[email protected]> wrote: > >> >> Perhaps I spoke too soon. I found that if I create a directory tree in >> one "file:" task: >> >> file: path=/top/dir/path/to/directory owner=user group=mygroup >> mode=755 state=directory recurse=yes >> >> only "directory" has the correct owner and permissions. But if I >> subsequently call file again and just specify the entry point to my tree: >> >> file: path=/top/dir/path owner=user group=mygroup mode=755 >> state=directory recurse=yes >> >> then the permissions and owner from "path" down were correctly set. And >> really, after thinking about it a bit, I wouldn't have wanted the first >> step to have set everything as that would have changed the permissions and >> owner on the upper level directories too, which is not what I wanted. >> Perhaps the module needs a "chdir" argument to move to the top directory >> (chdir=/top/dir in my example), and then "path" can specify a relative path >> instead of an absolute path. That way recursive permissions can be set >> from that point down. >> >> >> >> >> >> >> >> On Tuesday, July 29, 2014 2:19:06 PM UTC-7, [email protected] wrote: >>> >>> >>> So, a year and a half and several releases later, still not >>> working? It would be really nice not to have to set directory permissions >>> in a separate step. >>> >>> >>> >>> On Sunday, February 17, 2013 6:16:57 AM UTC-8, Michael DeHaan wrote: >>>> >>>> On Sun, Feb 17, 2013 at 1:42 AM, shadowy m <[email protected]> >>>> wrote: >>>> > Thanks for the link. As long as I know it's supposed to work I'll >>>> wait for >>>> > the fix I guess. >>>> > >>>> > Is there another way to do this in playbooks? >>>> >>>> >>>> shell: chown -R user foo && chmod -R 644 foo >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Ansible Project" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/ansible-project/b62ca1f0-ff9e-4548-b2c4-cef54a993196%40googlegroups.com >> <https://groups.google.com/d/msgid/ansible-project/b62ca1f0-ff9e-4548-b2c4-cef54a993196%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgzM%2B99MD9%3DK%2BV5vV%3DDZQmpNp105B%2BtRYoDghsp%3DRqpzPg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
