# Problems with remote unarchive on existing file **URL:** \ **Category:** Ansible Developer\ **Created:** [August 1, 2014, 6:20am UTC](https://forum.ansible.com/t/problems-with-remote-unarchive-on-existing-file/15830 "2014-08-01T06:20:56Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![willthames](https://avatars.discourse-cdn.com/v4/letter/w/8dc957/32.png) [@willthames](https://forum.ansible.com/u/willthames)\ **Post date:** [August 1, 2014, 6:20am UTC](https://forum.ansible.com/t/problems-with-remote-unarchive-on-existing-file/15830/1 "2014-08-01T06:20:56Z")
I’m using unarchive with copy=no and src=/tmp/archive.tar.gz dest=/wherever/ (i.e. the src is already on the machine and I just want to extract it under /wherever) It’s currently failing on the \_remote\_md5 check - it should be returning the string “3” because it’s a directory (and running the code locally on the machine prints out 3 and then exits) but stdout is actually empty. unarchive is in general a bit strange because it does an os.path.dirname on dest which actually removes the directory unless you add a trailing slash, even though this is not at all what the documentation suggests. I have a patch for that ([https://github.com/willthames/ansible/compare/ansible:devel...willthames:unarchive\_dest\_fix?expand=1](https://github.com/willthames/ansible/compare/ansible:devel...willthames:unarchive_dest_fix?expand=1)) but it doesn’t fix my md5 problem anyway (the only reason I tried it was to see if removing the trailing slash made the \_remote\_md5 test do the right thing) Any thoughts? The main logic is in lib/ansible/runner/action\_plugins/unarchive.py. I’m getting the message dest /wherever must be an existing dir ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [August 1, 2014, 2:29pm UTC](https://forum.ansible.com/t/problems-with-remote-unarchive-on-existing-file/15830/2 "2014-08-01T14:29:35Z")
What’s the question? About the md5 logic or whether to change the slash behavior? ---
**Author:** ![willthames](https://avatars.discourse-cdn.com/v4/letter/w/8dc957/32.png) [@willthames](https://forum.ansible.com/u/willthames)\ **Post date:** [August 2, 2014, 1:33am UTC](https://forum.ansible.com/t/problems-with-remote-unarchive-on-existing-file/15830/3 "2014-08-02T01:33:31Z")
Fair point. I just want unarchive to work at all, and preferably as documented. So my main question is whether anyone else is seeing this. Otherwise I’ll firm this up with better test cases. My secondary question is whether people are happy with unarchive’s behaviour not being as documented (well, I did write about it a few months back, but I’d be happy to update it - [http://willthames.github.io/tips/2014/04/17/using-unarchive-with-local-archives.html](http://willthames.github.io/tips/2014/04/17/using-unarchive-with-local-archives.html)) Will ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [August 2, 2014, 1:45pm UTC](https://forum.ansible.com/t/problems-with-remote-unarchive-on-existing-file/15830/4 "2014-08-02T13:45:04Z")
“Fair point. I just want unarchive to work at all, and preferably as documented.” Unarchive does have integration tests that proves it works in the integration test directory so it’s not like it doesn’t work at all, but it appears you have a bug report to file with copy=no, and there may be a problem there in some cases. That would be appreciated. “My secondary question is whether people are happy with unarchive’s behaviour not being as documented” I’m not sure why a blog post is a way to fix a project rather than contributing back to the documentation. Both of these points you make seem to just involve a slight bug in the copy=no handling, which was added after the original functionality of the module, and I agree would benefit from extending the existing integration tests. ---
**Author:** ![willthames](https://avatars.discourse-cdn.com/v4/letter/w/8dc957/32.png) [@willthames](https://forum.ansible.com/u/willthames)\ **Post date:** [August 3, 2014, 11:16pm UTC](https://forum.ansible.com/t/problems-with-remote-unarchive-on-existing-file/15830/5 "2014-08-03T23:16:11Z")
At the time I just thought it was odd - that note was really an aside in documenting how to use unarchive on already remotely downloaded artifacts. I didn’t think it was a way to fix the project. However, now I think it’s a bug. And I’m happy to update the tests, and implement the fix. Will ---
**Author:** ![willthames](https://avatars.discourse-cdn.com/v4/letter/w/8dc957/32.png) [@willthames](https://forum.ansible.com/u/willthames)\ **Post date:** [August 4, 2014, 5:49am UTC](https://forum.ansible.com/t/problems-with-remote-unarchive-on-existing-file/15830/6 "2014-08-04T05:49:44Z")
I’ve created an issue now that I understand exactly when the error occurs. [https://github.com/ansible/ansible/issues/8418](https://github.com/ansible/ansible/issues/8418) Will ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [August 4, 2014, 12:11pm UTC](https://forum.ansible.com/t/problems-with-remote-unarchive-on-existing-file/15830/7 "2014-08-04T12:11:47Z")
Ah, so this is password error handling stuff. Sure, fix would be quite welcome! ---
**Author:** ![willthames](https://avatars.discourse-cdn.com/v4/letter/w/8dc957/32.png) [@willthames](https://forum.ansible.com/u/willthames)\ **Post date:** [August 5, 2014, 12:47am UTC](https://forum.ansible.com/t/problems-with-remote-unarchive-on-existing-file/15830/8 "2014-08-05T00:47:43Z")
Yep, will endeavour to sort that one. Looking at unarchive, the problem is if the destination’s parent directory is not writable but the destination is writable. So e.g. for a standard user unarchiving into /tmp, it will fail through permission checks on / The integration tests succeed if you’re running them as instructed as the root user because the writeability checks never fail. I’ve added an integration test that fails test\_unarchive if you run it as non root using --tags test\_unarchive. [https://github.com/ansible/ansible/pull/8441](https://github.com/ansible/ansible/pull/8441) Will