Select multiple items (files, folders or mixed) in the Finder and run the macro.
In the first two actions you can set the path for the intermediate folder (where the items get copied to) and for the final archive. The intermediate folder will be deleted after archiving. (So be careful, and don’t set a path that already exists!)
This is all excellent info from which I can learn, for this particular use and for others as well – not just the compression options but file handling, etc. within the provided solutions. Greatly appreciate your time and effort.
I definitely don't want to create an additional step for my publisher by sending a zipped tar – I'm correct that he'd unzip the file from me, yielding a tar that he then needs to deal with?
Really not trying to be a difficult ingrate but I'll confess that there's a part of me saying, "...but... but all of this just to know when the compression step is done?" Still seems really strange to me that there's no way to "Pause Until compression completes." Am I crazy?
When your archives are intended for a specific recipient, it is clear that you have to respect his possibilities or wishes.
Concerning gzipped tars: This is a very common archive/compression format in the Unix world, comparable with zip on Windows.
If your client is on macOS or Linux he will be able to open .tar.gz / .tgz (or even .tar.xz / .txz) in one go. If he’s on Windows he will be able to open .tar.gz / .tgz (probably any unpacker can handle the format); if it is unpacked in one go may depend on the program he’s using. (Some programs have a “continue expanding” setting, some do it by default.)
But, as long as you use Apple’s tool (ditto on the command line, Archive Utility in the GUI) you can also safely create zips, without the tar part.
(Though I remember that back in the times were zip on macOS has started to become usable, there were often incompatibilities with certain Windows unpackers. So I guess, some “non-standard” adjustments to the zip format were necessary when they made it HFS-compatible.)
The problem as I see it is that it can be hard to tell from a third perspective if an archiving process really is finished. For example when you compress a big file in the Finder:
Archive Utility probably reads some hundred megabytes, compresses them and writes them to disk. Then it reads the next chunk and compresses it. At that point, from a third point of view (e.g. KM watching the folder), it can be hard/impossible to tell if the written archive is already complete or not.
That’s why @gglick proposed to do it with a shell script, because then the macro has to wait until the compression is finished, because the compressing program itself knows of course when the archive is complete and won’t stop before.
This is largely the same macro as the last one with ditto, just with Archive Utility instead of the ditto command line.
To get the desired “wait until compression is complete” effect we are using a particularity of Archive Utility: If the app is not running when invoked to compress/expand something, then it will auto-quit after the process is complete. (That’s why with the first action we make sure that it is not running.)
This is just to demontrate an alternative. I find the command line macro more elegant and less makeshift.
Attention: Like the rm -Rf in the previous macro, also this macro has a destructive delete-folder action. It will delete the path you have set in the Local Tmp Archive Folder variable! So, handle with care!
(Obviously, if you already have set Archive Utility (in its preferences) to delete the files after archiving, then you don’t need the last action. But I wouldn’t do this, because then it will always delete the source files, also when not working on a temporary directory as in the macro context.)
It allows you to compress via Finder File > Compress and should pause the macro until the process is completed.
Explanation: Archiving via Finder is done by a background process called ArchiveService. In the Pause Until action we test for the output of a shell script that checks the state of the ArchiveService process every 1 second. When compression is completed the state should go from R to S or Ss, and the macro continues.
Don’t know how reliable this is, but in a couple of tests it worked.
PS: To make it more economic you could increase the sleep to 2 or 3 seconds, and get the process ID with a separate, one-time shell script before the Pause Until action.
