Here's another idea then: use the zip command in an Execute a Shell Script action to zip the files that way rather than the Finder's compress menu. This way, the macro will wait until the shell script is complete before proceeding. As an added bonus, you can also eliminate the manual "selects all in displayed folder" action for a bit more reliability, and you can set how the zip will be named before the archive is created, either the same way every time the macro is run or differently via a prompt. For the moment, try customizing this and see if it works any better:
1 Like
OK, very cool. I will try this as soon as I can. It might not be today – I have different deadlines for different clients ATM!
But I greatly appreciate this.
Thanks!!
So that "append variable" step – in effect – selects all by loading their filenames into the var def, such that we end up with 1 zip, not 1 zip per file, correct?
I take the liberty to post a slight variation of @gglick’s macro.
Basically it does the same, it compresses all files in the current Finder window. The main difference is that is also works with spaces in path/file names.
The archive is placed on the same level as the source directory (not inside).
Zip All Files in Current Folder [modified i].kmmacros (2.2 KB)
Keep in mind though that the zip tool does not preserve all the Mac-specific file system stuff, like extended attributes, resource forks, comments, tags, …
If you want to preserve these, you should use ditto instead:
Zip All Files in Current Folder [modified ii].kmmacros (2.3 KB)
This should work exactly like the macOS Archive Utility, preserving all attributes.
1 Like
Ah. Vital info.
I've got to preserve all tags and comments, definitely – they're part of the product. These are music files being sent to a publisher who, like all film/tv music publishers, has conventions re: file naming, format, resolution, tagging style, etc. Noncompliance wastes his time, and that is not cool.
This macro is the second half of the process (well, the post-music-makin' process). I have another macro that takes 99% of the ugh... out of this pub's tagging and description process. I'm really loving KBM; relatively new to it.
To avoid misunderstandings: It’s only the command line zip tool that discards extended attributes. macOS’s GUI tool Archive Utility (as well as the Finder’s Compress command) preserves all information perfectly fine. (Probably Archive Utility is using ditto internally, since both can produce .cpio and .zip archives.)
Yep, I'm aware. That's why I started with Finder > Compress.
On the command line you have several options to create metadata-safe archives:
- As mentioned,
dittofor .zip and .cpio -
tarfor .tar -
xarfor .xar -
hdiutilfor .dmg (disk images)
Uncompressed archive types (.cpio, .tar) you can then further process with any compressor you like.
For the smallest possible files while preserving all Mac metadata you want lzma2-compressed tar archives (.tar.xz). On current macOS versions these can be expanded in the Finder with a double click.
Some time ago I’ve written an AppleScript that offers all available metadata-safe archiving methods in one place.
You can download it here.
1 Like
Thanks for stepping in with a much better and more comprehensive solution, @Tom. I still only know a little bit about shell scripting, and did not know that the zip tool doesn't include Mac metadata when I made my last post, nor even that ditto was a thing that existed. Between all the options you covered here, I imagine the OP should be able to find something that works well for this task.
1 Like
@Tom, a question from me about ditto if you don't mind. I tried to write my own macro that would use ditto to create a zip archive of the current Finder selection, but as far as I was able to figure out, it looks like it only allows for compressing single files or entire directories. Is there a way to use ditto with an arbitrary selection of files, like you can with zip? If not, is there another scriptable utility that can compress arbitrary numbers of files while retaining Mac metadata?
No, AFAIK it only works with single items (file or folder).
Yes, see my post above. For example tar (the Mac version) is metadata-safe. The tar archive you can then compress with whatever you want.
For ditto, you could also prepend an action to copy the selected files into a (temporary) folder and then let ditto archive that folder. If you’re on APFS, this will take no time or space, since files are “cloned” when copying on the same volume.
Ah, sorry about that. What I meant to say, but obviously didn't, was "is there a way to compress arbitrary numbers of files into a zip archive while retaining Mac metadata" 
Anyway, thanks for confirming! For my own needs, I am on APFS, so that temp folder method seems like it should work fine if that's the only way to go about it.
Well, at the time I wrote the script I linked above (2015 I think) I couldn’t find anything. But it’s possible that something new has grown in the meantime, or that I just have missed something.
Concerning zip itself, the man page says:
Mac OS X. Though previous Mac versions had their own zip port, zip
supports Mac OS X as part of the Unix port and most Unix features
apply. References to "MacOS" below generally refer to MacOS versions
older than OS X. Support for some Mac OS features in the Unix Mac OS X
port, such as resource forks, is expected in the next zip release.
…and I think this paragraph hasn’t changed for the last 10 or 15 years 
But what’s wrong with a deflated tar (.tar.gz or .tgz)? The compression algorithm is virtually the same as zip and I think any tool that can open zip can also open .tgz.
tar can also produce .zip files, but I guess then it is simply omitting the tar part, resulting in the same drawbacks as zip. (But I will test it tomorrow, to be sure.)
Quoting myself:
It’s not yet tomorrow, but I just tried it out. And yes, unfortunately tar behaves like zip when you use it to create a .zip archive (metadata gone).
Here is a macro to compress multiple items with ditto:
Compress Multiple Items with ditto.kmmacros (4.2 KB)
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!)
1 Like
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.
1 Like
Yep... OK. Good stuff for me to consider.
Again, I sincerely appreciate the help from both of you.
1 Like
Here another approach, using Archive Utility.app:
Compress Multiple Items with Archive Utility and Wait.kmmacros (5.6 KB)
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.)
Here another, more nerdy, approach:
Compress Multiple Items with Finder and Wait.kmmacros (3.0 KB)
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.