Ah, checking the creates clause _after_ extracting the file seems like a bug.

That said, mine tend to be around the 50Mb mark - but are you unarchiving
from a local file on the node, or directly off the network / control machine?

Even with files that small, up/downloading each time was pretty slow.
Instead we do
something like

- name: download kafka {{ kafka_version }}
  get_url: url={{ kafka_tarball_url }}
           dest=/root/{{ kafka_version }}.tgz

- name: extract tarball to {{ kafka_dir }}
  unarchive: src=/root/{{ kafka_version }}.tgz dest=/opt/
             copy=no creates={{ kafka_dir }}

On 28 January 2016 at 20:14, Tuomas-Matti Soikkeli <tsoikk...@gmail.com> wrote:
> Thanks for the answer.
>
> I tried that but this just doesn't overwrite the existing files. It takes
> the same amount of time than just overwriting.
>
> It's not that usable when extracting multiple GB's of binaries.
>
> Tar however skips the whole thing with --diff arg
>
> On Thursday, 28 January 2016 17:34:24 UTC+2, Dick Davies wrote:
>>
>> Try adding a creates: clause on the unarchive task, that might do what you
>> want.
>>
>> On 27 January 2016 at 23:18, Tuomas-Matti Soikkeli <tsoi...@gmail.com>
>> wrote:
>> > Is there any reasoning behind the fact that unarchive module using zip
>> > never
>> > checks the destination if the files already exists. This is quite
>> > inconvenient when extracting very large files.
>> >
>> > I understand that tar has --diff argument and it makes it easy to use,
>> > but
>> > It could be fairly trivial to implement this with python zipfile. It is
>> > already in in use in unarchive.py:
>> >
>> >
>> > https://github.com/ansible/ansible-modules-core/blob/devel/files/unarchive.py
>> >
>> > We could use ZipFile.infolist() to get filenames and file sizes and
>> > check
>> > them against destination. There's already a method which decides that
>> > zip
>> > files are always not unarchived:
>> >
>> >
>> > def is_unarchived(self, mode, owner, group):
>> >   return dict(unarchived=False)
>> >
>> >
>> >  I could definitely contribute if this sounds plausible.
>> >
>> > - t-m
>> >
>> > --
>> > 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 ansible-proje...@googlegroups.com.
>> > To post to this group, send email to ansible...@googlegroups.com.
>> > To view this discussion on the web visit
>> >
>> > https://groups.google.com/d/msgid/ansible-project/283e3ddc-d1a6-4885-a218-61b62fbf9e00%40googlegroups.com.
>> > 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 ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/CAK5eLPTyMB%2B0THT2Z1yNPHrKpJNpyzP1E04iYKGx6TgHVUeRzQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to