Unraring and deleting ('unarchiving' rars)

(Thought I'd share this for anyone else looking to do the same thing)

I wrote to support with this:

Trying to do this:

Open rar file and extract
Delete rar file
process extracted content

mimicking the automatic 'unarchive' process for zips. But by adding a 'move to trash' step after 'open with default program', some rars are moved to the trash before being extracted, and then fail since the file is in the trash.

I've been wondering for various actions how to create a delay, or an if > then set up (if rar has previously been extracted, then delete).

How would you solve this?

Paul responded (promptly, I might add) with:

You could try putting in a delay (like via a script) though the better solution is to track down one of the commandline programs that can unpack rars and trigger that via script. When done that way, Hazel will be able to wait until it is done before continuing.

This turns out to be dead simple.

Download the mac version here: http://www.rarlab.com/download.htm
(the rar is trialware, but the unrar component seems to be free)

Install the unrar component (this step borrowed from here: http://www.robertvenema.nl/journal/arch ... -mac-os-x/):

Code: Select all: $ sudo install -c -o $USER unrar /bin

Then in Hazel, add a shell script step:

Code: Select all: unrar x $1

then a 'Move to Trash' step

... and Bob's your uncle.

Not sure if you guys are checking out the beta but I did add rar support to the "Unarchive" action. The last beta added support for multipart rars as well. It will behave like it does with other archive types, where it unarchives the file, throws away the original(s) and then sets the target of subsequent actions to be the unarchived file. If there are multiple unarchived files, then they will be stuck in a folder which will then be the new target.

If you don't mind running beta software, then I suggest going over to the beta forum to get the details. I'd love to have people testing it.

Hi, not sure if this is old hat now or not but I would be interested in testing the beta for the RAR unarchiving ability.

I currently have a rule set on my downloads folder to move rar files (downloaded via speeddownload or safari) to a RAR folder. On the RAR folder I initially had a rule to check if the file is a RAR file and if it is, to unarchive it.

The problem I am having is that hazel is trying to unarchive each rar archive as it appears in the folder, which for multipart rars is useless and if the rar has a password, then it just bombs out.

Does the beta handle this kind of situation? Im currently using Hazel 2.3.4 (v608)

Many thanks,

Andrew

Update: Sorry Just noted that the previous post is for 2006 not 2009 as I initially assumed :oops:

But is there a way to do this with the current version that Im missing?

Yeah, the RAR unarchiving has since been released. It should work for multipart archives. Once it successfully unarchives, it should get rid of the rar and all its parts replacing it with the unarchived result. You are using the built-in unarchiving action and not a script, right? Also, it can't deal with passworded RARs since that requires user interaction. You'd need to do that in a script in such a case.

Hi,
Thanks a lot for responding, I'm using the built in archiving/unarchiving function and not script but what seems to happen is that it is trying to unarchive each part of the rared-file as its moved into the folder instead of waiting for all of the parts to be moved.

For example I have it checking my downloads folder and moving rar files to a RAR folder and what I would like is that it will unarchive the files in the RAR folder, which in turn then checks the type and moves them elsewhere afterwards. At the moment once rar-file-part1 is moved into the folder, its trying to unarchive it immediately, without waiting for the other parts to be present.

For now Ive switched off that particular rule and do it manually, the other rules checking for type etc afterwards are working great, so I just need to suss this out for the whole process to be automated.

Yeah, Hazel can't really know when you're done downloading all the parts. You can download everything to a different folder and then dump the files into the folder Hazel is monitoring when they are all there. Or you can try and put in a delay depending on how reliably/quickly all the parts can be downloaded.

Hello,

Since i mostly deal with multipart rar´s i thought id use this script, but it does not handle spaces in the filename... i only get an error. The log says:

Cannot open /Volumes/Downloads/OSX_Extracted/Clueless.rar
No such file or directory2010-02-12 22:33:19.521 hazelfolderwatch[38566] [Error] Shell script failed: Error processing shell script on file /Volumes/Downloads/OSX_Extracted/Clueless Syndrome.rar.
2010-02-12 22:38:19.359 (null)[0] Clueless Syndrome.rar: Rule Unarchive RAR matched.

Any time you refer to arguments in a shell script, you have to quote it or else it will fail on spaces or other odd characters. In short, something like this:

Code: Select all: unrar x "$1"

Is it possible to add an option to the Unarchive action to NOT delete the RAR files upon completion?

I'm trying to unarchive a multi-part RAR and then run subsequent actions on the resulting file without deleting the original archive and I'm not sure how to do that without getting into Automator actions or scripting, neither of which I'm any good at. Any suggestions?

No. The unarchive function acts as if it is transforming the archive into it's unpacked version. What you could try is having Hazel copy the archives somewhere else and the have another set of rules to monitor that folder and unarchive them. You may still have timing issues of one end starting to archive before the other end is finished copying all the parts over though.

Mr_Noodle wrote:No. The unarchive function acts as if it is transforming the archive into it's unpacked version. What you could try is having Hazel copy the archives somewhere else and the have another set of rules to monitor that folder and unarchive them. You may still have timing issues of one end starting to archive before the other end is finished copying all the parts over though.

Yeah, I was hoping to avoid that.

Is that an option you can consider for future versions?

Thanks!