Hot Door CORE Forum

Full Version: hdicoreFiles ungzip
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Can someone tell me the correct format to archive a file so that hdi::core::files::unzip can expand them? Is this the same as the default setting for the Mac OS X Archive Utility, the one with the convenient right-click contextual menu? Or the same as Windows 10 send to > zip archive? I'd like to retrieve and install plugin version updates in a manner that's easier for users than having the openURL function simply download the file via a browser for them to manually place in the Plugins folder.

Also, is there a recommended method to take the contents of a POST and save it to disc as a file? I suspect once the file is created, expanding and moving it to the Plugins folder is pretty intuitive using the files functions.

Thanks!
I think you're possibly misreading the function name, it's "ungzip()"

A gzip file is not the same as a zip file, but is easy to create on either platform with the right app. There are lots of compression methods out there, so perhaps gzip won't be the right one for your specific use case (though it'd probably be fine); we included it because we needed some compression internally and because licensing issues made it the simplest choice.
Thanks, Garrett. Sorry about the missing G (thank you auto-correct).

But the G in gzip was my cause for concern, seeking a simple cross-platform uncompression solution. Although one can gzip files from a terminal window (and script it to make quick work of a tedious task), it sees an .aip file as a directory and won't compress it without the common practice of tar-ing it first, which then negates the CORE function. I'd like to stay within the CORE library as much as possible, so this should be an interesting project.
I've been struggling with this off and on for a few years now. Files::ungzip docs says it doesn't understand gzipped tar files, but Mac plugins have to be tar archived in order to be gzipped. That's a Catch-22 for me unless there's some way to gzip directories without tar first, which seems cannot be done. Is there a way that I just haven't found?

Alternatively, or actually better yet, is there a simple cross-platform C++ library someone can recommend for a CORE plugin project to extract compressed zip (not gzip) files? I see a lot of them on the internet but they all seem to have dependencies or are just confusing for me to figure out. I'm a bit out of my wheelhouse trying to uncompress files and automatically install plugin updates for my customers.
On Mac I would recommend calling out to the command line from within your C++ code and simply using the built-in macOS program /usr/bin/unzip. The macOS Foundation framework's class NSTask makes sort of stuff pretty easy.
I ended up using this to extract zip files: https://github.com/kuba--/zip

You just need three files: zip.h, zip.c and miniz.h. 

The only code needed to expand the archive looks like this:

Code:
int zipResult = zip_extract(zipPath.c_str(), tempFolderPath.c_str(), NULL, NULL);

It works well on both Mac and Windows. Be aware that if an archive contains a .DS_Store file, the zip_extract function will fail. I only extract zip archives that I previously made, and the script that creates them automatically excludes .DS_Store.

Code:
do shell script "cd " & myLocation & "; zip -r " & zipFile & " " & myFolderName & " -x *.DS_Store __MACOSX"

To convert my GET data to a zip file, here's a bigger chunk of code:

Code:
std::string theGETdata = this->iGET->content();
free (this->iGET);
this->iGET = NULL;
std::string sTempFolder = HDI_CORE_ILLUSTRATOR->folderPath(hdi::core::Illustrator::TemporaryFolder);
std::string zipPath = sTempFolder + "zipFile + ".zip";
std::ofstream outfile(zipPath.c_str(), std::ofstream::binary);
outfile << theGETdata;
outfile.close();
int zipResult = zip_extract(zipPath.c_str(), sTempFolder.c_str(), NULL, NULL);
std::remove(zipPath.c_str());

This is the last piece I need to place updated plugins directly into the user's plugins folder. :-)
I should note that this technique for retrieving and installing plugin updates only works on macOS. Under Windows, the CORE function to move the old plugin to the trash fails, as does the generic "remove" command. At first I thought it's the permissions of the enclosing folder (448) but it seems in Windows (and only Windows) Illustrator keeps the file open until it quits. Looks like it's back to the drawing board since the new plugin can't replace the old one until Illustrator quits. :-(
This is going off on a tangent, but once an updated plugin is expanded from the downloaded archive, how can one move it to the Windows Plug-ins folder, since the old file is still busy while Illustrator is running? Does that require a script that runs after Illustrator quits?
A while ago we decided we had too many issues with that approach, and switched to downloading a complete Windows installer exe (still gzipped). Then we just ungzip after download completion and launch the exe, allowing the user to complete the installation process (after they quit Illustrator too of course).