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...?
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:
opens url of client's upload site
activates the Finder and has me confirm that a few things are org'd properly before continuing
selects all in the displayed folder
selects File > Compress
pauses until the front window name matches the "to be uploaded" folder (rather than the prog window - this is another thing I tried that didn't work)
pauses another 10 seconds just to be safe, since the above isn't completely doing it
renames the zip according to the client's conventions
selects the part of the name that I need to edit per project
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:
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.)
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.)