In praise of ClouldPull -- bring your Google Drive files to your Mac's local storage

There are a lot of spreadsheet and documents on my Mac, representing years of work, that have contents that look like this:

{"url": "https://docs.google.com/open?id=17c7ZAr5....XI”, “doc_id”: “17c7....VloXI”, “email”: “jgordon@kateva.org”, “resource_id": "document:17c7Z...unVloXI"}

Yes, they’re stubs referencing data stored in Google’s cloud as “Google Docs” and “Google Sheets”. That’s what Google puts on Google Drive on my Mac, and why so much data takes up so little storage. (Beware, however, of Google Drive/Photos integration. That’s bad news.)

It means that I don’t really have ownership of any of those files. I can use Google Drive to “reorganize” my Cloud drive, but I generally can’t work with that data offline [1].

Which is one of the reasons I like CloudPull - a $25 Mac app that still runs on Mavericks [2]. It creates local backups of my Calendars (VCALENDAR), Contacts (VCARD 3.0), and my Google Drive. I can ask for a complete backup, or I can only create backups for Google doc (as Microsoft Word, dock) or Google sheets (as Excel, .xlsx) and let Google Drive handle all the readable files.

It even holds 1,500 Google Reader liked articles left over from the end of Reader.

The data is stored in my User Library Application Support folder, but I really should move it back into my Docs folder.

Most of the time I can ignore all of this content, but it’s a great reassurance to have it at hand. Every Mac user of Google Services should own CloudPull.

[1] So when I drag something out of the drive, and it’s “deleted”, what happens if I open the stub file? What does Google do to enable offline use, and how scary is that? Curious stuff.

[2] I’m going to Yosemite with 10.10.4. Too many apps need Yosemite now, and as good as El Cap sounds it won’t be ready for me before Feb 2016.

Mavericks bug: enabling iCloud Keychain duplicates Contacts if use .me domain

This is a truly weird bug.

If I enabled iCloud Keychain sync in Mavericks all of my Contacts would duplicate. One set would show up with the header of 'iCloud', the second (new) set would have the heading 'iCloud jf" where jf are my (true) initials.

The two sets appeared truly identical. Edits to one appeared in another. My iPhone Contacts were not affected.

If I turned off iCloud Keychain sync I could unclick Contacts in iCloud preferences and watch one set disappear. Then it would check itself back on. I unchecked again and a second set disappeared. Then I rechecked it and the first set of Contacts returned Lastly I reenabled iCloud Keychain and the second set of Contacts reappeared.

I think this bug is related in part to the .me to .iCloud transition. I say that because my iCloud account used the old '.me' domain. It's supposed to be interoperable with iCloud, but I guess it really isn't. I signed out of everything on my iMac and left iCloud, then restored using the '.icloud' domain. Now I have one set of Contacts and I have Keychain sync enabled.

Curiously, even after the fix, the Accounts setting in Contacts shows the .me suffix. I can't edit that, it claims to be inheriting from Preferences. iCloud support in Mavericks is a real hack. I probably can't wait for El Cap, will need to accept Yellowstone after next bugfix release.

Google Photos is a wrapper over Picasa Web Albums

Google Photos uses the Picasa Web Albums API, it doesn't have its own API:

• Google Plus API & photos? - Stack Overflow - use Picasa Web Album URL
• image - Google Plus Album Urls - Stack Overflow - all Google+ Photos are Picasa photos. You can get albums back as JSON too

No wonder my Picasa web albums showed up so well in Google Photos and why so many G+ features are missing -- Google chose to build on old Picasa rather than G+. It also explains why my old Mac Picasa uploader (works in Mavericks) is the best way to get images in albums to Google Photos.

The Google Drive integration, by the way, is a dangerous hack. Avoid it for now.

The Picasa uploader doesn't support Google Photo's image compression format (WebP?), so I wonder if those images will count against storage totals.

I hope we get an API, particularly with support for creating or selecting albums at upload time, any minute now...

Domain configuration - notes on www and naked domains

I’m writing this primarily for myself. I’ll try to update it as I learn more.

 

I’ve used DreamHost for years, I have several domains there. Recently I created one for our mountain bike team - hpmtb.org. I set it up as “Fully Hosted” and created a few subdomains so I could create a subdomain like http://fb.hpmtb.org that would redirect to our Facebook site. (This is probably not the best way to do this, maybe better to use Apache URL rewrites with .htaccess)

 

I was even able to get a wiki.hpmtb.org subdomain to work properly with wikispaces.

 

That’s when I ran aground. I wanted the naked domain, or www.hpmtb.org to point to that same wiki page. As best I can tell, with DreamHost, you can’t do that through DNS or domain configuration. For one thing, www.domain.com and domain.com are treated by DreamHost as synonyms. You can’t really have them behave differently.

 

For another DreamHost, for a fully hosted domain, sets up a fixed type A DNS record to reference DreamHost’s IP address.

 

Can this be done for a DNS only configuration, with hosting disabled?

 

I think there’s a way to do it with Google Apps, in particular I’m pretty sure there’s a way to have a naked domain or www.domain reference a Google Site. I’m just not quite sure how to do it. Clues might be in these references ...

• DNS basics - Google Apps Help: Create blank A record for 216.239.32.21. Note Google then redirects www to gas.googlehosted.com
• Enable your "naked" domain address - Google Apps Help
• About CNAME records - Google Apps Help
• About A records - Google Apps Help
• Configure A records - Google Apps Help: check out the values and IPv6 support with AAAA

Phew. This is a tiring domain to explore. Not only is it fundamentally complex, the documentation is marginal (Google has the best, but it’s Google Apps specific) and experimentation is hard. It’s easy to mess up a domain, and changes can take time to propagate. There are lots of quirks; I discovered Chrome will cache DNS redirects, so if you make a change and Chrome doesn’t seem to know about it try incognito mode. Good luck!

 

Domain registrar transfer pains - something broken between eNom and Dreamhost (or me)

I've transferred several eNom domain with associated Google Apps services to Dreamhost. This is the first time I've been really stuck.

I'm trying to move kateva.org from eNom to Dreamhost. Dreamhost already provides DNS services, so it's "simply" a registrar transfer. I've done several of those.

This time the process is failing after I get an "authorization key" (EPP) from eNom/Google and I complete the Dreamhost authorization key submission. Instead of receiving a Google email (takes 1-2 hours):

STANDARDIZED FORM OF AUTHORIZATION
DOMAIN NAME TRANSFER - Confirmation of Registrar Transfer Request ...

I get radio silence. Tech support tells me Dreamhost's system shows a transfer status of denied ...

kateva.org Canceled - Invalid EPP/authorization key - Please contact current registrar to obtain correct key

We've been through this twice now with two keys. So I think something is broken (yes, user error cannot be ruled out, this is a complex process).

Unfortunately level one tech support doesn't know the details how this status shows up in their system. (They also can't explain why Dreamhost doesn't expose this status in the user accessible control panel or generate an email. I think there's a hole in their workflow process, but this could also be a bug in their system.)

At this point I'm hoping I can escalate to tier 2 support. Then I can interview somebody who should know how the status code is generated, and whether the bug is with Dreamhost (already known to have a process problem) or eNom (gonna be hard to talk to) or me (always possible).

Frustrating, but other than lost time worst likely outcome is I renew with eNom for another year. Then try again in 6 months and hope whatever is broken gets fixed.

Update 6/5/2015: Dreamhost tells me they're getting a formal transaction from eNom: "Invalid EPP/authorization key - Please contact current registrar to obtain correct key". So now I have to contact eNom at 425-274-4500. May the Force be with me.

Facebook still has RSS feed for Pages. For the moment.

Once upon a time Facebook had RSS support for personal Newsfeeds. That died years ago.

I don't know if Facebook ever had RSS support for Groups; Groups used to be pretty limited. They don't now.

Pages though, they've always had RSS feeds. It's just getting a lot harder to find.

I may be dreaming, but I thought there used to be an official RSS link somewhere. If so it quietly passed on, maybe in the last 6-12 months.

The old Feed URL format still works though:

https://www.facebook.com/feeds/page.php?id=121212

where the number is the Page ID.

The trick is finding the Page ID. Facebook keeps moving it around. As of June 2015 find it here:

1. Click About link beneath Page photo (Timeline, About, Photos, etc)
2. Find Facebook Page ID at bottom of the About Link.

Google Photos, Aperture and Google Drive - be careful

I'm a fan of Google Photos.

Sure, the next time Google's coin flips Evil side up my kids will appear in ads for laundry detergent. I get it; I'll delete my Google Photos then. I'm resigned to 2 year lifespans for Cloud services -- which is why I keep local control of things I care about.

It's not like there are good alternatives. Facebook? Many of my relatives don't use it. Smugmug? Expensive, can't do shared albums. Flickr? They've blown it so many times. Dropbox? I fear the end is in sight.

Apple? Seriously? Apple? Oh, I get it. You were pulling my leg.

So, Google. Among other things it means I can keep using Aperture for another year, hoping for better than (ugh) Photos.app 2015.

Uploading from Aperture is awkward though. There's no Export Plug-In, my old Picasa plug-in died when Google terminated its ClientLogin API last week. If I use the Google Photos desktop web UI I have to export to JPG from Aperture with a unique common string in the file names, upload all files, then do a search/create to put them in a Collection (album).

I'd rather use Google Drive. In theory I can create a folder in a special Google Drive "Google Photos" folder and export from Aperture to that folder, managing "albums" as file system folders. I can probably even use some Symbolic Link so the "Google Photos" doesn't use precious SSD space. Google Drive will do all the sync for me. Very nice -- in theory.

In practice, even though my non-Plus Google Photos service showed my Google Drive/Google Photos the albums don't appear. When I tried toggling the 'special folder' off in Drive settings the folder vanished from Google Drive (a problem if you're not ready for your photos to disappear). When I look at a different Google Photos folder through the web UI of Google Drive I see:

Riigght. The Google Drive/Google Photos integration isn't yet working properly for non-Plus personal (not Google Apps) users. 

So be careful. I'll update this blog post if/when it works.

Update 6/1/2015: Don't use Google Photos integration with Google Drive.

A day or two after my initial post there are two Google Photos links browsable in the web client view of drive.google.com and one Google Photos folder in my desktop Google Drive collection.

The Drive_Google Photos link above now shows a view similar to iOS Photos.app, or photos.google.com but without collections. 

Within "My Drive", and also on my desktop Google Drive, is a folder called Google Photos that holds all of my Picasa photos organized by dates, not by collections/albums.

You can add folders and images to the "My Drive" Google Photos folder. They will sync like any other Drive data, but they won't show up in photos.google.com or Photos.app.

I've read you can move images around in Google Drive, but this does not affect images on Picasa/Google Photos.

If you delete images from Google Drive:Google Photos, however, they will be deleted from photos.google.com/picasa. (I probably deleted a bunch doing these experiments.)

So the only thing Google Photos integration with Google Drive is good for at the moment is getting a local copy of the images (but not the album organization) of your Google Photos/Picasa images. It's also a great way to unwittingly blow away all your Google Photos.

This has NOT been though out. I'm disabling Google Drive/Google Photos integration and I urge you to do the same.