Hi, all -
I sincerely apologize if I've missed this, but I've searched this forum and the help and not found it.
I want a Pause Until "compress X items" completes in the Finder. As a test, I tried a Set Variable to Text action where I found that the progress bar during compression has Copy as its name. But using that with Pause Until Front Window Title does not equal Copy did not work for me.
Am I misinterpreting how that should work, or doing it the hard way, or...?
Thanks much!
Since the built-in compression utility always names compressed files as "Archive.zip" by default, you can use this path condition to determine when the compression is complete:
Pause Until.kmactions (691 Bytes)
Hi, and thanks!
Two things:
Which tool are you using? With 10.15.3, when I compress a 3GB-file via the Finder’s contextual menu, the archive appears only once it is completed.
However when I drag the file onto Archive Utility in the Dock, then the archive appears when the process starts.
For the latter case I tried it with this…
…but it triggers already when the compression process is halfway completed. (But not immediatly when the archive appears.)
But if you are using a different compression tool (with a different caching or temp file behavior), it might work. To test.
I'm initiating the compressing via KBM using File > Compress x... . That "ignore partial..." is great to know about; thank you for that!
The KBM macro, at this early stage but already functioning well enough for really nice time/fuss savings:
and that's it.
Suggestions happily welcomed! I know there's more I can do with what's here, but I'm on a deadline and have to take care not to spend all my work time building macros to turn in the work I haven't done yet. 
Weird. On my system the Compresss from the Finder’s File menu behaves exactly like the Compress from the contextual menu, that is, the archive appears only once it is complete. So the Folder trigger works fine, with or without Ignore Partial. (On my machine/system.)
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:
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.
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:
ditto for .zip and .cpiotar for .tarxar for .xarhdiutil for .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.
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.
@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.)