Noodlesoft Forums

I use a Hazel rule to archive and rename files with a pseudorandom name before uploading and sending someone a link. This is part of a workflow for improved security in sending files inspired by Merlin Mann.

The Hazel rule does not perform the archive and rename action on xlsx files. I understand that these files do not match because one of my conditions is "Kind is not archive", and xlsx files are essentially structured zip files.

My question is: how can I modify the rule so that xlsx files are processed just like other files: zipped into an archive with a pseudorandom file name?

Here is the current rule:

If all of the following conditions are met

• Date Added is in the last 1 minute
• Kind is not Archive
• Kind is not Folder

Do the following:

• Archive file
• Rename file with pattern: [custom date/time pattern][extension]

This works great for most files, like .txt, .pdf, etc. -- but does not work for .xlsx files. Any assistance you can offer is appreciated.

Thank you,

Daniel Mann

You can create another rule to match those files specifically.

Note that in 3.0, you will be able to do nested conditions so you would be able to do this all in one rule.

Alright, I tried matching those files with the condition:

• Extension is xlsx

...but unfortunately that did not produce the desired result. While the rule did match and run on the file, the extension was left as .xlsx, and the file could still be opened directly as a spreadsheet. The goal is to preserve the original file intact, including the filename, archiving it inside a pseudorandom-named zip file.

Next I tried changing the "Rename file" action to "[custom date/time pattern].zip". This appeared to work at first glance, but when attempting to unzip the file, I found that the original .xlsx file was not preserved; instead, it was just renamed to .zip. Unzipping this file results in unarchiving the contents, which are themselves not usable as a spreadsheet.

So, the "Archive file" action in Hazel does not appear to archive (into a .zip file) what is perceived as an existing archive file with a .xlsx extension.

Any suggestions for actions to achieve this?

Thanks,

Daniel Mann

I'd have to dig deeper to see why it isn't archiving but it's usually not a good idea to compress and already compressed file. Could you send me a sample xslx file? I don't have Excel. Just use the "Contact Support" button in the "Info" pane and attach the file in the resulting mail window.

Update:

I just ran a test where I took a zip file and renamed it with a .xslx extension. I had a rule to archive xslx files and it worked, making it into a .xslx.zip file.

So, I suspect the error is somewhere in your config. Make sure you double-check the rule preview and the logs. Send me any logs you think are relevant.

Mr_Noodle wrote:I'd have to dig deeper to see why it isn't archiving but it's usually not a good idea to compress and already compressed file. Could you send me a sample xslx file? ... Just use the "Contact Support" button in the "Info" pane and attach the file in the resulting mail window.

Just sent a sample .xlsx spreadsheet file. Apologies for any overlap; I had not refreshed the page to see your update before sending.

Mr_Noodle also wrote:I don't have Excel.

Wish I didn't need it! After resisting for years, I finally caved and bought a copy so that I would not have to keep running a Windows VM just for spreadsheets. Now I only boot the VM for Windows administrative tools a couple of times a week.

then Mr_Noodle wrote:Update:

I just ran a test where I took a zip file and renamed it with a .xslx extension. I had a rule to archive xslx files and it worked, making it into a .xslx.zip file.

So, I suspect the error is somewhere in your config. Make sure you double-check the rule preview and the logs. Send me any logs you think are relevant.

That's possible... but if you wouldn't mind testing with the file I sent, I would appreciate it. In my testing I could get Hazel to append or change a file extension, but the .xlsx file was simply renamed, not archived inside a new zip file.

Interestingly, I can right-click a .xlsx file in Finder and choose the Compress option, which does archive the file into a new zip archive named filename.xlsx.zip. When unzipping this file, I get back the original filename.xlsx file. This seems to match what you're seeing.

I created a new rule to test futher:

Conditions:

• Extension is xlsx

Action:

• Archive file

That's as simple as I can get, and Hazel does match the rule, but does not archive the file. Here is the log output:

Hazel wrote:2012-01-31 20:40:25.462 (null)[0] 20120131-test.xlsx: Rule zip xlsx file matched.

Can you share your rule conditions, actions, and results? (Especially whether the resulting .zip file can be unzipped to recover the original .xlsx file?)

Thanks for your continued assistance with this.

Daniel Mann

Update: we have a workaround!

Mr_Noodle was able to replicate the issue when I sent a sample .xlsx file, and recommended I try using a shell script for this instead of the built-in archive action.

While I'm pretty comfortable at a bash prompt, zipping files is something I usually do graphically. Still, I gave it a try, and after a bit of fiddling, got everything working the way I wanted.

Here's the embedded script I'm running in the Hazel action to zip .xlsx files:

Code: Select all

zip --junk-paths `date +%S%H%M%d` $1
rm $1

Notes:

• $1 is the placeholder for the file matched by the rule
• the zip command in its basic form is 'zip output input', where 'output' is the name for the resultant archive, and 'input' is the file or files you want to archive
• `date +%S%H%M%d` is parsed into a date format: second, hour, minute, day of month -- this is my pseudorandom filename
• --junk-paths tells zip not to include parent folders of the input file in the archive ($1 is the full /path/to/file value)
• the second line, 'rm $1', simply removes the original file after it has been archived, keeping my filesystem clean

Hope this helps someone else!

Daniel Mann

Thanks for posting the script. Also, I'll be looking into fixing the problem in 3.0.

One suggestion for the script is to enclose the $1 within double quotes. This will allow the script to handle paths with spaces in them, among other things.

Hi Daniel,

Here's a one-liner version of your script with a few minor (and unnecessarily pedantic?) changes:

Code: Select all

zip --junk-paths --quiet $(date +%S%H%M%d) "$1" && rm -f "$1"

Notes:

• Wrapped $1 in double-quotes to handle, for example, pathnames containing spaces. [edit: as Paul's post that snuck in before mine suggests]
• Used $(…) instead of `…` for date command expansion because I think it's more easily readable.
• Added --quiet option to zip command to quell unneeded output.
• Used && rm … conditional list so $1 filename will only be removed if zip command result has a zero exit status.

Using full pathnames for /usr/bin/zip, /bin/date, and /bin/rm commands would be another possible change. And maybe adding the #!/bin/bash shebang as the first line of the embedded script to ensure it's interpreted with bash.

Good suggestions all around. Thanks for helping to refine the solution.

Here's my latest version, tested successfully on Mac OS X Lion 10.7.3 with Hazel 2.3.10 (v721). I now have a single Hazel rule that handles zipping up all my file types with pseudorandom zip file names.

Code: Select all

/usr/bin/zip --junk-paths --quiet $(/bin/date "+%S%H%M%d") "$1" && /bin/rm -f "$1"

Notes:

• using full paths for commands (lookup paths using 'which', e.g. 'which zip')
• enclosed date format string in quotes (in case someone modifies this to include other characters)
• did not include shebang; shell is specified in Hazel for embedded script

I don't know if the full command paths are really necessary, but I do tend to include them in other scripts, so why not use them here too?

Thanks again for all the terrific input.

Daniel Mann

theterran wrote:enclosed date format string in quotes (in case someone modifies this to include other characters)

Ha - I'd thought about suggesting that, too, using single quotes.

did not include shebang; shell is specified in Hazel for embedded script

Ahh, thanks for the reminder.

I don't know if the full command paths are really necessary, but I do tend to include them in other scripts, so why not use them here too?

As an alternative to specifying full pathnames for every command, which sometimes gets tedious and redundant, I can be satisfied using a limited, ordered command search path like:

PATH=/bin:/usr/bin
export PATH; readonly PATH

It's still possible to override that for specific commands if there's a reason to.

Thanks again for all the terrific input.

Thanks for positively accepting it.