iCloud Drive: Don’t do what I did!

Being deeply immersed in the Apple ecosystem, a couple of years ago I made a decision:

I’ll move all of my work files onto iCloud Drive!

I work (as in, write code and edit image files) mainly on my Mac. But I was seduced by the possibility of accessing all of my work files in a pinch on my iPad (which I still had at the time) or even my iPhone. Plus, since my files would be in “The Cloud”, I could even access them from another computer (or from my Mac when booted into Windows) if I needed to, by logging into my iCloud account from a web browser.

It seemed… so obvious. So perfect.

Umm… maybe not.

For the past two years, I have been constantly fighting with iCloud Drive. One of its signature features is that it can manage disk use on your Mac automatically, so as your hard drive fills up, it deletes files you haven’t used in a while, keeping them safely in the cloud while freeing up disk space on your Mac. And with my MacBook Pro sporting a (meager?) 256 GB hard drive, with 40-odd GB allocated for a Windows partition, and over 60 GB occupied by Logic Pro X sound samples, my drive is filling up constantly.

While this is great in principle, it is completely unworkable in practice for three interrelated reasons:

  1. If you have a large amount of data in play here (for me, it’s in the vicinity of 100 GB), iCloud Drive may get to a point where it is constantly transferring data. If you’re not on a gigabit fiber connection, this can both use up all of your Internet bandwidth and take ages.
  2. Because #1 is taking place constantly, if you do find yourself needing to grab one of those files that has been deleted locally (as indicated in the Finder by a cloud icon with a down-pointing arrow), you may find yourself waiting several minutes for the file to become available, even if it’s small (as in, under 1 MB).
  3. In an effort to make this all appear seamless to the user, the Finder represents cloud-only files as… regular files. But they’re actually just pointers with a hidden .icloud filename extension… as you’ll find if you ever try to perform Finder actions inside another program, such as syncing files to a web server using Transmit.

All of this might be tolerable if Apple gave you any control whatsoever over which files get deleted locally. But they don’t.

It gets worse.

What’s worse than getting stuck in this situation? Trying to get out of it. It’s like quicksand… the more you struggle against it, the faster and deeper you sink into it.

I made the decision earlier this week to extricate myself from the iCloud Drive nightmare, by buying a 250 GB SanDisk external SSD. First off, a little unpaid plug for this drive… it is awesome. It’s super light and small, seemingly at least as fast as the internal SSD in my MacBook Pro (in that I am able to transfer multiple gigabytes of data in seconds), and it even looks cool. I’m going to be using it all the time, so I’m actually considering putting adhesive Velcro on both it and the top of my MacBook Pro so I can keep it permanently attached. (Which says a lot about how much my regard for Apple has fallen lately — in the past I would never have sullied the exterior of an Apple laptop with something adhesive.)

So anyway, external SSD acquired, my goal was to start transferring my files from iCloud Drive over to the SSD.

Uh… good luck with that.

Because I’m now at a point where I have more than double the amount of data stored on iCloud Drive as I have available space locally, a majority of my files are now only in “The Cloud.” Ugh. Which means waiting for all of that data transfer stuff to happen. If only I could, somehow, bypass this broken process, I thought.

There has to be a way.

tl;dr Nope.

So, here’s the thing. I’ve been using iCloud Drive for the bulk of my cloud-based file storage, but I do use other services as well. I have Google Drive. I have Dropbox. I know how they work.

Specifically, I know that you can, y’know, like, select a folder and download the entire thing as a zip file.

So I thought to myself, I’ll just go to iCloud in a web browser and do that! Download the whole friggin’ thing as a big zip file, or maybe a few zip files, and be done with it.


For whatever reason, iCloud doesn’t let you do that. Probably because of the whole seamless “It just works” Kool-Aid drinking song everyone in Apple land has been singing. (Myself included, mostly.)

You can only download individual files, not folders, from the iCloud web interface. It does let you select multiple files at once, but only within one folder.

Check out this delightful thread full of know-it-all asshats whose response to a legitimate question — why doesn’t Apple allow this thing that every competing service does? — is to challenge the validity of the question and the intelligence of the questioner. (That thread is now closed so I’ve just opened my own new thread on the topic. Watch this space for trolls!)

There. Are. Plenty. Of. Reasons. A. Person. Might. Have. For. Needing. To. Do. Something. That. You. Have. Not. Previously. Considered. Stop challenging their premises and answer their question, or shut the hell up.


I ended up “solving” the problem by resigning myself to the fact that it wouldn’t be completely solved. So instead I took the drastic approach of temporarily logging out of iCloud completely, just so I could strand the files I did have saved locally, and copied them to the SSD.

Then I logged back into iCloud Drive and tried to get it to stop syncing my files by unchecking the Desktop and Documents Folders option.

The only problem is, I didn’t have my work files in those folders. I had them in a separate top-level folder in the iCloud Drive that I created myself. Because, you know, you can do that and it didn’t seem like a crazy idea or anything.

It was.

I discovered this morning that even though I had done all of this and tried to purge the nightmare of constant iCloud Drive syncing from my Mac life, once I had logged back into iCloud, the Mac went right back to quietly, constantly, syncing that iCloud Drive data on my Mac. As I type this, I have a Finder window open to my iCloud Drive and in the status bar it says “downloading 120,079 items (36.14 GB of 48.66 GB)”. Fun!

So, my new plan for today is to watch that window, and as the little cloud icons next to individual folders goes away, I’m copying those folders to my SSD and then deleting them from iCloud. My assumption is that as I do this, I am freeing up more local space and iCloud will continue to download the remaining items, and eventually I’ll have everything transferred over.

But please… do yourself a favor and don’t do what I did. iCloud Drive is not suitable for professional use.

Proof that music and techno-geekery go together (or, Why Paul Slocum is my hero)

I’ve been a fan of Paul Slocum‘s various projects for several years now, but this takes the cake. From his blog post about a new project:

The program generates house music by progressively calculating the digits of pi and feeding them into an algorithmic music generator that I wrote…

The song is infinitely long and static. Every byte of the audio output is predetermined, even though only a small amount of it has actually been listened to. So you can jump to any measure in the song and it will always play the same music for that measure.

And it gets only more delightfully geeky from there.

A useful tip if you love both YouTube and markup validation

Not valid!YouTube is worlds apart from the likes of MySpace (*shudder*) when it comes to good code, but like most massively influential sites, they don’t really seem to care that much if their code validates, and even less if the code they provide webmasters for embedding content in their own sites does.

Frankly, I usually don’t care that much about validation either. I worked in this field for too many years when no validators even existed, and I’ve always taken the pragmatic approach: make it look and work the same, more or less, in all reasonably recent versions of Internet Explorer and Netscape (with Firefox and Safari having replaced Netscape over the past few years), and be done with it.

But I still have to admit that it’s a bit embarrassing that the “Valid XHTML” link (which appears in the Meta sidebar by default in WordPress) proves just how not valid my XHTML really is. I checked it today and was shocked to find 76 errors. I was relieved, however, when I dug in and discovered that only three of those errors had been my own. I had nested a <ul> inside a <span> (which I honestly didn’t even realize was a mistake, although I understand why it’s wrong, and it was easy enough to change from <span> to the valid <div> without any visible difference), and I had omitted alt attributes from a pair of images that don’t need to be identified by page readers anyway (and would probably be better off being worked into the CSS somehow).

These were pretty minor errors, if I do say so myself. 67 of the remaining 73 errors originated in cut-and-paste code blocks I got from PayPal and LinkShare (the latter of which I deal with only very reluctantly because they provide the mechanism for Apple’s iTunes affiliate program). What a surprise that the code from these sources looks like it was written by a tech support grunt in 1996 (in other words, by me in 1996)!

These were easy enough to fix, as well. I’ll just need to remember to fix them again if I ever change the code in those ad blocks, which I’m sure I will. The final 6 errors were the result of a YouTube video embedded in one of my blog posts. Ah yes, the age-old <object> vs. <embed> conundrum. I’ve always hated <object> because it seems unnecessarily complicated, with a slew of nested <param> tags that could just as easily have been attributes of the tag itself (although I suppose the point was to allow new parameters to be added without having to add support for new attributes in the DTD); plus it reeks of Microsoft’s platform-dependent ActiveX crapfest. I especially loathe the presence of, and need to hunt down, a ridiculously long, completely arbitrary clsid string representing the file format of the embedded file. (What’s wrong with a freakin’ MIME type?)

Unfortunately, the cleaner and more straightforward <embed> has never been part of any HTML specification, so it doesn’t validate.

Now it appears that there’s a solution to embedding YouTube videos in an XHTML-compliant way. Huzzah! But that means I’ll have to go back through all of my posts that have YouTube videos in them (which is a surprisingly large number) and fix them. It should be easy enough to hit them all at once with a well-constructed SQL query; I just need to study the pattern and do it. In fact, if I’d spent the last 15 minutes studying the problem instead of just complaining about it, I’d probably be done already.

But sometimes, complaining’s just more fun.