# Could this be a bug in copy module?

**URL:** <https://forum.ansible.com/t/could-this-be-a-bug-in-copy-module/13591>\
**Category:** Ansible Project\
**Created:** [October 1, 2013, 7:48pm UTC](https://forum.ansible.com/t/could-this-be-a-bug-in-copy-module/13591 "2013-10-01T19:48:00Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![Steven\_Truong](https://avatars.discourse-cdn.com/v4/letter/s/df705f/32.png) [@Steven\_Truong](https://forum.ansible.com/u/Steven_Truong)\
**Post date:** [October 1, 2013, 7:48pm UTC](https://forum.ansible.com/t/could-this-be-a-bug-in-copy-module/13591/1 "2013-10-01T19:48:00Z")

</div>

Hi all,

I happened to name my file that has a string “raw” in it and copy module failed to do the right thing. Is there a list of reserved keywords that we should not use?

Thanks,  
Steven.

print module\_args

# run the copy module

if ‘raw’ in module\_args:

# don’t send down raw=no

module\_args.pop(‘raw’)  
module\_args = “%s src=%s original\_basename=%s” % (module\_args, pipes.quote(tmp\_src), pipes.quote(os.path.basename(source)))  
return self.runner.\_execute\_module(conn, tmp, ‘copy’, module\_args, inject=inject, complex\_args=complex\_args)

---

<div class="post-metadata">

**Author:** ![Kesten\_Broughton2](https://avatars.discourse-cdn.com/v4/letter/k/ecc23a/32.png) [@Kesten\_Broughton2](https://forum.ansible.com/u/Kesten_Broughton2)\
**Post date:** [October 2, 2013, 7:57pm UTC](https://forum.ansible.com/t/could-this-be-a-bug-in-copy-module/13591/2 "2013-10-02T19:57:14Z")

</div>

I’ve stubbed my toe on several variable naming issues.

Add these to the list of variable names to avoid

names.with.dots  
names-with-dashes

Both give weird error messages.  
elasticsearch.yml uses dot-separated names, so i’m not sure what the problem is with ansible group\_vars/all vars.

kesten

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\
**Post date:** [October 2, 2013, 8:23pm UTC](https://forum.ansible.com/t/could-this-be-a-bug-in-copy-module/13591/3 "2013-10-02T20:23:57Z")

</div>

Yes, the variables section will soon clearly indicate you should always use valid variable identifiers.

---

<div class="post-metadata">

**Author:** ![Steven\_Truong](https://avatars.discourse-cdn.com/v4/letter/s/df705f/32.png) [@Steven\_Truong](https://forum.ansible.com/u/Steven_Truong)\
**Post date:** [October 4, 2013, 9:36pm UTC](https://forum.ansible.com/t/could-this-be-a-bug-in-copy-module/13591/4 "2013-10-04T21:36:04Z")

</div>

Hi Michael,

In my case, it is just a parameter for copy module (src=draw.repo) and why the copy module (sorry for my ignorance) even failed to copy a file with name that has the string “raw” in it. Is it too extreme?

There must be good reasons but I have not really read the code to understand the reasons.

Thanks in advances,  
Steven.

---

<div class="post-metadata">

**Author:** ![Kesten\_Broughton2](https://avatars.discourse-cdn.com/v4/letter/k/ecc23a/32.png) [@Kesten\_Broughton2](https://forum.ansible.com/u/Kesten_Broughton2)\
**Post date:** [October 4, 2013, 11:12pm UTC](https://forum.ansible.com/t/could-this-be-a-bug-in-copy-module/13591/5 "2013-10-04T23:12:21Z")

</div>

steven, are you sure it’s not the “.” in the name. If you define  
draw.repo: “value” somewhere, i know that will fail.

vars:

- anything.anything # this will fail

- draw.repo: “blah” # this will fail

- anything-anything # this will fail

- draw\_repo" “blah” # this is fine

- debug: msg=“{{draw\_repo}}” # no problems here.

---

<div class="post-metadata">

**Author:** ![Steven\_Truong](https://avatars.discourse-cdn.com/v4/letter/s/df705f/32.png) [@Steven\_Truong](https://forum.ansible.com/u/Steven_Truong)\
**Post date:** [October 4, 2013, 11:32pm UTC](https://forum.ansible.com/t/could-this-be-a-bug-in-copy-module/13591/6 "2013-10-04T23:32:28Z")

</div>

print module\_args

# run the copy module

if ‘raw’ in module\_args:

# don’t send down raw=no

**module\_args.pop(‘raw’)**  
module\_args = “%s src=%s original\_basename=%s” % (module\_args, pipes.quote(tmp\_src), pipes.quote(os.path.basename(source)))  
return self.runner.\_execute\_module(conn, tmp, ‘copy’, module\_args, inject=inject, complex\_args=complex\_args)

Hi Kesten,

This is the part of the copy module that bombed out every time I ran my module. Going back to my first message, I printed out the module\_args and there is nothing that is illegal there. Files have filename.extension and how can you avoid that entirely in dealing with files in any environment.

module\_args.pop(‘raw’)

This line clearly is the issue for my use case.

Steven.

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\
**Post date:** [October 4, 2013, 11:33pm UTC](https://forum.ansible.com/t/could-this-be-a-bug-in-copy-module/13591/7 "2013-10-04T23:33:51Z")

</div>

I don’t see why the pop command would split around this but please make sure there is a github ticket so we can reproduce and investigate.

---

<div class="post-metadata">

**Author:** ![Steven\_Truong](https://avatars.discourse-cdn.com/v4/letter/s/df705f/32.png) [@Steven\_Truong](https://forum.ansible.com/u/Steven_Truong)\
**Post date:** [October 4, 2013, 11:37pm UTC](https://forum.ansible.com/t/could-this-be-a-bug-in-copy-module/13591/8 "2013-10-04T23:37:27Z")

</div>

Hi Michael,

As soon as I changed my src=draw.repo to src=dbrid.repo, things will just work. Otherwise, I would have been sitting here waiting for others to fix this bug before I could get anything done.

I will file a bug.

Thanks and see you at AnsibleFest in SF.

Steven.

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\
**Post date:** [October 6, 2013, 2:29pm UTC](https://forum.ansible.com/t/could-this-be-a-bug-in-copy-module/13591/9 "2013-10-06T14:29:36Z")

</div>

This is now fixed on the development branch.
