Is There Food?

by Daniel Woolstencroft

Photostream Management with Hazel

The other day I read a post by Federico Viticci on moving your photos from iPhoto to Dropbox as a “management app”. I’d pondered this in the past, especially when Dropbox increased everybody’s base storage amount. I’ve never committed and gone through with it though, although I have stopped using iPhoto and replaced it with managing my own folders. When photos are coming in from potentially lots of different devices, I’d rather manage them myself.

Plus, I was never a fan of iPhoto’s “would you like me to delete all these photos now, I’ve copied them all into my library, honestly I have” prompt. I just don’t trust it. I want to see the photos with my own eyes, before I let an app delete them forever.

After Federico’s post, Stephen Hackett posted his own version of the approach, along with an Applescript technique for moving photos from Photostream into Dropbox. But something nagging in the back of my mind said “surely Hazel can do that?” and so I set about to see if it can.

Turns out it’s possible, and I tweeted Stephen to let him know. I thought I’d post this as a more permenant home for the solution because, well, Twitter.

I don’t use Hazel as much as a should. These days I have a Mac Mini running all the time as a server, so it makes sense to start getting Hazel to do more for me. Mail rules are another “thing” I need to get my head around, but that’s an entirely different post!

So, to Photostream and Hazel. The special sauce to make this work is an option in Hazel called “run rules on folder contents”. Photostream creates subfolders on the file system for every photo; instead of…

“\photostream\photo1.jpg”

…you get…

“\photostream\long guid based id\photo1.jpg”.

You need Hazel to dig down into each folder in the top-level Photostream folder, and treat each folder it finds as a folder to process.

To make this work I added two rules, like this:

hazel step 1

Then the first rule is extremely simple:

hazel step 2

The second rule is where Stuff Happens. Because the first fule contains “run rules on folder contents”, the second rule happens on each folder within the Photostream directory.

hazel step 3

Note: the iPhone Camera Roll folder in the screenshot above is just where all my iPhone photos end up. Just to clarify any “why copy from Photostream back to the camera roll?” confusion.

This isn’t just useful for Photostream, anywhere you want Hazel to process a folder full of folders, you can use this option.

My next trick is working out how best to take two Photostreams and mash them together for archiving.

Statamic Debug Panel

You’re seeing this panel because _display_debug_panel is true in your site settings.

Page rendered in: 0.220504s

values: 
  template: post
  layout: default
  statamic_version: 1.8.1
  php_version: 5.5.15
  theme: foundation-4
  environment: live

counts: 
  files: 
    opened: 26
    written: 1

  parses: 
    yaml: 13
    markdown: 2
    smartypants: 9
    statamic_tmpl: 11

  plugins: 
    theme: 24
    current_date: 1
activity: 
  debug (13ms): 
    0.0079s: timing
    0.0041s: counting
    0.0013s: timelining

  parsing (115ms): 
    0.0624s: statamic_tmpl
    0.0368s: yaml
    0.0132s: smartypants
    0.0026s: markdown

  config (20ms): 
    0.0198s: finding

  caching (52ms): 
    0.0387s: content
    0.0130s: settings
    0.0007s: member

  hooks (10ms): 
    0.0063s: finding
    0.0038s: running

  math (0ms): 
    0.0002s: hashing

  content (33ms): 
    0.0228s: getting
    0.0093s: preparing
    0.0013s: supplementing

  plugins (67ms): 
    0.0545s: theme:partial
    0.0108s: theme:js
    0.0010s: current_date:index
    0.0007s: theme:css
timeline: 
  0.0000s: --------- start
  0.0059s:     ~6ms  autoloaders ready
  0.0465s:    ~41ms  bootstrapped
  0.0487s:     ~2ms  app created
  0.0489s:     ~0ms  app configured
  0.0493s:     ~0ms  localization ready
  0.0515s:     ~2ms  app defaults set
  0.0954s:    ~44ms  caches updated
  0.0979s:     ~3ms  routes started
  0.1079s:    ~10ms  hooks initialized
  0.1082s:     ~0ms  segments determined
  0.1086s:     ~0ms  routes determined
  0.1298s:    ~21ms  content found
  0.1335s:     ~4ms  status determined
  0.1366s:     ~3ms  template picked
  0.1367s:     ~0ms  layout picked
  0.1520s:    ~15ms  template rendered
  0.2178s:    ~66ms  layout rendered
  0.2198s:     ~2ms  page ready
  0.2205s: --------- end