The general situation is that change detection on a tree of 5000 files would be remarkably slow. People think they want that, they do not.
AFAIK chmod/chown as shell tools do not have a return code option, settable by flag or otherwise that returns whether anything was changed. If they did, we would be able to shell out to it and you could use a "changed_when" based on the return code result. Doing it in python with 5000 (+) stat calls would not be pretty. On Tue, Jul 29, 2014 at 7:56 PM, <[email protected]> wrote: > > No, it worked as it should have each time. The first time I called it > with the full path to the bottom leaf directory and that created all of the > intermediate directories. The second time I called it I specified just the > entry point to the directory tree and that change the owner and permissions > of the intermediate directories from that point down to the bottom leaf. > Still, it would be more convenient if I could specify the entry point > and the bottom leaf in one call instead of splitting this across two calls. > And the advantage of using the "file" module each time instead of using a > "shell" task is that the file task can report whether a change was made or > not while a shell task will always report "changed". > > > > On Tuesday, July 29, 2014 4:18:33 PM UTC-7, Michael DeHaan wrote: > >> " 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/025841e9-c938-4a82-925f-6c876e4446c6%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/025841e9-c938-4a82-925f-6c876e4446c6%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%2BnsWgzYtVEsdg9QbuhAFkPoH%2BkoNzH5QAPuOJ7-9PAu2kxstQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
