I believe it is just that no one has implemented that yet however I vaguely recall looking into it once and finding that it would be harder to implement than I had originally thought. If you take a look at what tar --compare checks: https://www.gnu.org/software/tar/manual/tar.html#SEC66 it seems to be file size, mode, owner, modification date and contents. IIRC, I think checking some of those with zip wasn't as easy as looking into data structures that were available from the ZipFile API (some may have been extensions to the zip standard which would need a fallback and others may not have existed at all... I can't recall). It would certainly be nice if we could do this but if zip files don't have enough information inside to do that it might be easier to figure out why creates= is too slow for you and fixing that.
-Toshio On Thu, Jan 28, 2016 at 12:14 PM, Tuomas-Matti Soikkeli <[email protected]> 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 <[email protected]> >> 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 [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/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 [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/5ec86ad6-15a4-40ec-a819-72c77bf3cc9c%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 [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/CAG9juErrAF6Te6Cmm817A5ddDX_sFhEtGp6XjNnJQei3mkk8Ug%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
