I began seriously using computers late in life. It wasn’t until graduate school that I even owned one. In 1998 I got my first computer, a beige G3. The original G3. It ran Mac OS 9, of course, because that’s all there was, but I loved it, and it’s on this computer that I really cut my systems teeth. It was the beginning of what would later become my career in systems.

A few years later I got my first real systems job at an art school in New York City. In the interview I claimed that there was “no Mac problem I couldn’t fix,” confident in my knowledge of the simple Mac OS. Little did I know there were major changes on the horizon.

At that job there was a QuickTime Streaming Server under my purview. It ran Mac OS X Server 1.0 and provided me my first experience with what would eventually become Mac OS X. It was very strange looking, had UNIX shell access, and was not like any Mac I was used to using. I can’t say I ever quite fully understood that system, but it did give me a good deal of advanced experience, a chance to learn about what was coming. It was like that Terminator arm that Cyberdyne finds that leads to the rise of Skynet and the end of the world. I have to admit, I found it terrifying.

Mac OS X Server 1.0

When Mac OS X 10.0 finally came out and I began poking around its internals, that fear crystallized. This was an entirely new animal, far more complex and mysterious than my simple, easy-to-manage Mac OS 9. Suddenly I had our UNIX sysadmin knocking on my door, wanting to look at it, trying to show my how to use the command-line. I would have none of it. “Sure, the command-line is useful,” I’d say, “but it’s not the Mac way.”

Mac OS X 10.0

Nonetheless, as the new platform progressed I found myself forced to learn more and more about it. And the more I learned, the more I realized some things. For one, it turned out I really liked Mac OS X. Here was a system that, while infinitely more complex than its predecessor, was infinitely more powerful as well. I also realized that, though it was challenging, I was capable of handling the new OS, and capable of learning far more than I ever realized. But, perhaps most importantly, I discovered that I liked learning about Mac OS X. For the first time I realized that I liked systems work in and of itself. That realization, for me, was life changing.

As time went on, the OS became increasingly sophisticated, and I grew more confident in my abilities along with it (these days I’m even pretty proficient in the command-line). Before long I was doing lectures on the OS and had solidified a career in systems administration.

Mac OS X 10.6

It’s now ten years later, and the OS is fully mature, advanced even. And I’m still doing systems administration and finding it fascinating. It’s a trend that doesn’t seem to have an end in sight.

These days I work for a prominent New York museum and my job involves far less Mac administration and far more programming. I’ve built a web app and even learned how to program certain video hardware as well as the mysteries and intricacies of serial data. It’s all been on-the-job training, learning on the fly. But without those formative experiences with Mac OS X I doubt I’d ever have had the confidence to do what I’m doing now. Mac OS X taught me that I was good with technology, that I enjoyed it, and that my capacity for learning was far greater than I ever realized. These were powerful discoveries that have led me to where I am in life. So I just wanted to acknowledge, here, at the end of the decade, my admiration and affection toward this amazing piece of technology.

Firefox Startup and Home Page Settings

But I seem to remember that there was once a way to enable this feature while also having Firefox open new blank windows, that is, empty windows with no web page loaded. I believe this was an independent setting in Firefox 2, but now the only place I see such a setting is in the startup behavior, and I’ll be damned if I’m going to turn off my session restore behavior.

By default, Firefox 3 opens all new windows with your homepage. If you try to leave this setting blank, Firefox 3 will use its own branded Google search page. But there is a way to tell Firefox to make your home page an empty one. Instead of using a URL in the Home Page field of the Main preferences tab, use about:blank. By doing so you’re telling Firefox that a blank page is your home page, and thence onward Firefox will open all new windows empty, blank, bare as white paper. And that is just great.

Much Better!

If you’re like me, you don’t need to see your home page every time you open a new window. In fact, there’s no page I want to see every time I open a new window. It seems like a goofy default. I wish the Firefox devs would either bring back the preference to open new windows sans content or change the default to a blank page the way it is with new tabs. It just makes more sense.

Until they do, though, I’ll be setting my homepage to nowhere.

Though the option may be gone from the GUI, however, it still exists in the command line version. Rob Griffiths solution is to use the command:

softwareupdate -d

There are a couple problems with this. The first is that the command, as listed in Mr. Griffiths article, doesn’t do anything, at least not when I run it. From what I can tell the command requires the -a flag. So if you want it to actually work, it should look like:

softwareupdate -d -a

This will download everything you don’t already have to a directory that the Software Update app can see (/Library/Updates). Now we’re off to a more promising start.

The other problem with this method is that it doesn’t offer a great deal of things you normally get with the GUI. In particular, as Pierre Igot points out, you don’t get a progress indicator. Which really blows, I agree.

You also don’t get prompted to install the updates once downloading has finished. To that end, I’ve written a little Automator Service. The service, when launched from any Services menu in any app, will prompt you to continue with this confirmation box:

Once you click OK, the download will begin. When the download is complete, the service will copy the new updates to an Updates folder at the top level your home account (~/Updates) for safe keeping.

Once copying has finished, the Software Update app will launch and ask you if you want to install the updates you just downloaded. Just install as normal. Let Software Update do its business.

In the end everything will get installed and you’ll be left with copies of all the updates in your home account for later use, all with only a single download.

While I can’t really offer a progress bar, I like this better than the alternatives. It more closely approximates the old “Install and Keep” Software Update method than having to go and open the Terminal and do all that stuff as individual steps. And it’s almost as user-friendly, being activated from a drop-down menu, just like Software Update usually is.

So here it is. The Software Update Download service:
Software Update Download Service

Download it, unstuff it and put it in ~/Library/Services. You should be able to launch it from the Services menu in any application.

A minor disclaimer: this service has mostly worked well for me, but there was one instance in which it seems to have had troubles. In particular, it seemed to choke on the latest iWork ’09 updates. This may have been a fluke, or it may have had something to do with that particular update. I honestly don’t know. But if you have troubles, let me know in the comments of this article. I’ll do my best to figure out what’s wrong as I’m using this in my own workflow. But consider this a beta at best; it’s been through minimal testing.

Also, you should be able to open the workflow up in Automator and make adjustments to the behavior if you so please. Feel free to do so and let me know about it in the comments.

Enjoy!

It’s Personal
In the Archives post I basically said I’d be archiving all my “non-essential data” to hard drives and reserving optical media archives for only the most essential archives. I should first point out that what I am talking about here is my personal data. This is not necessarily a method I’d use at work or for a client. Archive methods should be specific to the needs of the situation.

The Future
One of my rationales for using hard drives was that hard drives are more likely than optical to be accessible in 10 years with the equipment of the day. It’s this particular idea that received a great deal of criticism, and I’m starting to see why.

Just a few weeks ago I had occasion to archive some museum kiosks that ran from some very old PowerMacs. Luckily, these PowerMacs were just barely of the era when ATA drives were starting to be used as internal drives on Macs. Getting the data off these systems was fairly straightforward. I simply hooked PowerMacs’ the ATA drives up to a firewire case and archived the data to DMG. Shortly thereafter, however, I wanted to perform a similar process with a slightly earlier vintage PowerMac. This machine, however, contained a SCSI drive. And finding a way to access and archive this drive proved almost impossible without going to extreme lengths and making obscure hardware purchases. Had there been some kind of optical archive of these systems, I would have almost certainly been able to pull a backup using today’s equipment.

I’m not sure what the future of optical media is. Until recently, I was pretty convinced it was not long for this world and would surely be displaced as a distribution medium by the web. But after thinking on the comments to that article, and talking to people way smarter than me on such matters, I realize I may be wrong. And if that’s the case, optical will be more likely to be readable than hard drives ten years in the future. But whatever the case, this is certainly true for media from ten years ago. You’re more likely to be able to read ten year old optical media than you are hard drives of that era.

Non-Essential Data
That said, I’d like to clarify the “non-essential data” qualifier I tossed in in the article. To be clear, I’m not completely eschewing optical media for my archives. What the article represented was my shift from optical as my only form of backup to hard drives as a significant if not primary form of data backup and archive.

To get even more specific, in the past I archived everything to optical media. But with the huge amounts of data I now collect, that’s not really so practical anymore, nor is it necessary. So these days the bulk of my data — large, non-essential data, things like ripped DVDs, video captures from tape, software installers, and data with a shelf life (i.e. that is only useful for a period of time or that relies on old versions of software or hardware) etc. — will be archived to hard drive. This will allow easy storage and retrieval. And it should last long enough. The idea is that this data isn’t forever data. It’s stuff I want to keep around for a while, but if I haven’t needed it in ten years, I probably won’t ever need it again.

More important data — of which there’s really not that much, but stuff like big video projects (sans captured media), photos, my websites, contacts, stuff that would really kill me to lose — I’ll be burning to optical. That way I have double backups of it (I’ll also keep it in the hard drive archive), and I’ll have it on a more robust medium that may have a better chance of being readable than hard drives in the future.

So what’s really going on here, for me, is a prioritization of my data backups that’s reflected in my archive procedures. With this prioritization, I can now rely much more heavily on hard drives as an archive medium. Using hard drives I can back up and access a lot more stuff with much greater ease and speed. Doing this allows me to use optical media only for the most important data. But make no mistake: optical will still be an important component in my backup strategy.

Live Archive
I wanted to also take a minute to mention one way hard drives are somewhat future-proof and useful as a true archive, and this is the idea of a live, rolling archive.

In the lab where I used to work we kept — or tried  to keep — a long-term archive of all student work that was accessible to incoming students so that they could look at and benefit from the work of their predecessors. Our students made all sorts of work, from web projects to video and animation projects to installations. And their work was initially being archived to all manner of media, from tape media to optical. There was no standard. By the time I got involved there were projects going back ten or fifteen years, and it was becoming clear that, no matter what medium we used today, we’d need to re-archive everything every so often as data access techniques and hardware evolved. I believe that, in a case like this, where the archive is constantly growing and reaches back well over ten years, but to which access is always required, the concept of the hard-drive-as-archive-medium is a sound one. The implementation would be fairly simple in concept: everything — the entire archive — is kept on a hard drive to which the community has access. As the archive grows, say every few years, it is transferred to larger storage. As storage standards change, it is transferred to the latest greatest medium of the day. Of course, redundant backups are also kept of the entire archive. But since this data is constantly being re-archived, hard drives — or whatever replaces them in the future — make for a sensible way to have a rolling, live archive, and reduce the need for more permanent solutions like optical. Perhaps Chucky, in the comments to Archives, put it best:

“In other words, hard drive archival demands cycling your backups over time to new hard drives with fresh magnetic media and evolving HD interfaces.”

I guess the overarching lesson here, if there is one, is that your archive method should reflect the specifics of your situation; there is no one archive method for everyone. The corollary to that, for me, is that hard drives can (and will) now be a significant part of my archive method.

Then I read it.

It turns out to be an incredibly thorough, yet brief, technical description of the term Cloud Computing. The article does a great job of defining Grid Computing and then uses that definition as point of comparison to arrive at a very real and very useful definition of The Cloud. I’ll be a little less embarrassed to use the term after reading it. Only a little. But still…

Well worth a read for anyone who needs some clarity on the whole Cloud thing.

“You really tell people to reboot for no particular reason?

I don’t believe we should accept that standard from OS X, and what kind of an IT person are you if you’re blindly proposing solutions without any reasoning to back them up?”

What kind, indeed.

I posted a response to the comment that basically explained my position in a nutshell, but I thought it was worth writing a follow-up on the question, both for thoroughness and for those who didn’t happen by the comments section of the previous article, or who may have had a similar reaction.

Reboot!

When a user comes to me with a problem, my primary goal is to fix the problem and get the user working again. Typically what happens is that we have a little discussion about what’s going on. Once I feel I have a good handle on the symptoms, often the next words out of my mouth are, “Did you reboot?” If the answer is no, and the situation permits, I will recommend that they do so. Rebooting is often my first step in troubleshooting.

I believe (though I can’t be completely sure) that my commenter took issue with the approach because blindly telling the user to reboot to solve problems gives the sysadmin no information about what those problems are and what caused them. But in fact, as I’ll demonstrate in a moment, it’s not blind, and it does tell us one important thing: rebooting either solves or doesn’t solve the problem. This in and of itself can be crucial troubleshooting information if there is a deeper problem at work.

But the fact of the matter is that, probably 80% of the time, there is no deeper issue. The fact is that rebooting routinely fixes problems with no other practical solution, such as the one I described in my article. Moreover, it provides the end-user with a method of troubleshooting that is likely to achieve the desired results — allowing them to get the system or an application back to a working condition — without the need for admin intervention. This is win-win: it saves both the user and me time and energy and, by determining whether or not a reboot is helpful, still provides valuable troubleshooting information.

I would even argue that rebooting should almost always be the first step in troubleshooting. When a user comes to me with a problem, I have no idea what they’ve been doing on that system. I have no idea how many nor which applications they have open. I have no idea what sorts of preferences they’ve set. There’s simply no way for me to reliably predict the state the user has put their machine in, and thus whether or not this is a system- or user-level problem. The only way for me to get things back to some semblance of a known, working state is to reboot the system. Rebooting has myriad benefits, not the least of which are: clearing stale caches; recreating network connections; and freeing up RAM and disk space. In fact, it seems almost crazy to proceed with most troubleshooting without first rebooting.

You may have noticed that I keep saying that rebooting should almost always be the first troubleshooting step. That almost is there because, obviously, there are times when rebooting is not a good first step. Primarily, when a user stands to lose work by rebooting. If an application is hung and the user hasn’t saved his document, for instance, I don’t tell them to reboot. Rebooting would be bad in this instance. Also, I usually try other troubleshooting methods first on my own systems, with which I am better acquainted (though this is often to my own detriment and rebooting would have been quicker and easier, as happened with the Final Cut bug).  Another instance in which I avoid a reboot is when there is a persistent problem that is not solved, or is only temporarily solved, by a reboot. Then I do need to get on that system and attempt to understand a problem. And that’s what I do.

But, because Mac OS X is very reliable on the whole, these instances are extremely rare in my experience. The majority of problems are minor and are easily and permanently rectified by a simple reboot. I stand behind that recommendation, and any search of Mac troubleshooting articles will reveal that the advice is almost universal. That’s because it works.

So, hopefully it’s clear by now that I’m not “blindly proposing solutions without any reasoning to back them up.” Hopefully it’s clear now that there are a lot of good reasons to try rebooting as a first troubleshooting step.

And hopefully it’s clear that the kind of sysadmin I am is the kind that likes to get his users back up and running again with a minimum of friction.

Let’s start with a rundown of the existing approaches.

Roaming Profiles
The approach Windows computers use is called Roaming Profiles. The way Roaming Profiles work is pretty simple. Users’ home account data is stored on a centralizd server. When the user logs in to a client system her data is downloaded from the server to the client machine. She will access her data locally for the duration of the session. When she logs out the data will be synced back up to the server. The advantage of this approach is that the user has local access to her data and isn’t beholden to the network while actually working. This makes data access generally faster and more reliable. The big disadvantage here is that if the user makes any big changes or creates any big files, a large data transfer will happen at log out, and then again at login to subsequent machines that aren’t yet synced to the server. This both slows down the login/logout process and places an often undue burden on the network.

Because of the sorts of environments I tend to work in — data-intensive, video and image oriented facilities that create a lot of data — my experience with Roaming Profiles has been fairly poor. For my uses they’ve required a lot of management and have been somewhat unreliable. But, for the purpose of maintaining a user environment across multiple networked systems, they work well enough if you understand and plan for their inherent limitations.

Network Home Accounts
The method used by *NIX systems, Mac OS X included, for time in memorial, is generally referred to these days as Network Home Accounts. In the Network Home Account model, as with Roaming Profiles, the user’s home account data is stored on a server. But when the user logs in using Network Home Accounts no data transfer occurs. Instead, the home account data is accessed directly from the server: new files are written directly to the server; settings files are read directly from the server; everything happens over the network and the network share that contains the user’s home account data is treated just like a local volume. The speed advantage over Roaming Profiles at login and logout is obvious; there’s simply no lag time as data gets transferred between the client and the server, because there simply is no data transfer. On the other hand, accessing your entire home account over the network can be slower than a local account even on the speediest of networks. And on slower networks, or networks with a great deal of traffic, you’ll definitely notice the slowdown. There are also potential problems due to the constant reliance on the network and server. If the network becomes congested or the share becomes unavailable even for a second you’re liable to feel the pain. If either goes down you’re dead in the water until they’ve returned to service.

As network home account models go, I like this one the best. I’ve used it a great deal in educational settings in which resources are almost completely shared and it’s fairly reliable and usable. But even this model can be frustrating and is less than ideal when compared to working from a local home account.

Portable Home Directories
The final model is called Portable Home Directories. Devised by Apple for laptop computers with occasional — but not constant — access to the network hosting home account data, Portable Home Directories attempts to combine the best of the Roaming Profile and Network Home models by providing finer-grained control over the sync process in what is otherwise a Roaming Profile approach. So, Portable Homes sync to specific data at specified times when they’re on the network. Fine-grained control over what is synced and when is intended to mitigate performance issues at login and logout.

My main problem with this approach is that, in my admittedly limited tests, it doesn’t seem to work very well. I also don’t like the level of management required. The other models, once set, require little if any tweaking whatsoever. But I could see spending a great deal of time and effort getting my Portable Home Directory settings just so.

The Problem
But my overarching beef with all these models is that they don’t really jive with the way most people in most of the environments I’ve encountered actually use their computers. This makes them use system resources less efficiently and yields a poorer user experience than if they did.

So how do most people work? Well, what I’ve tended to see in the media-based environments in which I’ve worked is that users are generally assigned a single computer. It’s this computer from which they work almost all the time. Indeed, this is how I work in my current job. I’m almost always working from the computer in my cubicle. Almost.

Every now and then, however, I need to work from a different machine, and there are often times when I’m doing this that I realize that it would be extremely handy to have my entire home account — all my environment settings, files and folders — available to me on this other machine. But I don’t. They’re over there, on my cubicle machine. If only I could use the home account on my main computer directly, as thought it were a Network Home Account.

And this is the basic idea behind Satellite Home Accounts.

Satellite Home Directories
All the current models rely on the user’s data being stored on and accessed from a centralized server. But why? Why can’t the server be the user’s main computer? In the Satellite Home Account model, the user’s primary computer becomes the home account server for any user that sets her account as a Satellite Home Directory.

The way I envision it, it would actually be quite simple to set up. In the Accounts preference for the user would a be a tickbox to activate Satellite Home Directories. Once activated, the user’s system would begin broadcasting Satellite Home Directory information, just like Mac OS X broadcasts Network Home Account info. The user would then work locally as normal, but when logging into another system on the network — a system that’s listening for SHDs — the user would be presented with her home account over the network, shared directly from her primary system rather than from a centralized server. Simple.

Among the great benefits of this system are its simplicity and the fact that it requires no server. But the chief advantage comes from the fact that the Satellite Home Directory system works the way users tend to work. When you’re on your main computer, which you are 99% of the time, you get a fast, responsive, local home account. When you move temporarily to another system, your environment follows you. It’s a bit slower, sure. But hey, it’s only temporary. The network overhead is significantly reduced from the other methods, and the user experience is also enhanced. It’s win-win.

There’s certainly no technical reason an implementation like this would be impossible or even particularly difficult. Most of the technology already exists, either in Mac OS X client or Server. All we need is for someone to program it. And while I doubt there’s likely much interest on Apple’s part to build something like this, I really think it’d be damn sweet.

And a boy can dream, can’t he?

Subscribing to a Single Calendar
The first thing that’s not readily obvious is how to connect to your CalDAV calendars. It is possible to subscribe to multiple Google calendars, for instance, but doing so is neither straightforward nor apparent. Still, once it’s done it’s done, and it’s mostly better than the alternative.

Subscribing to a single Google calendar — your main Google calendar, if you only have one — is really what the iPhone is interface is designed for. Where to do this is also not necessarily obvious:

1. Open the Settings app.
   

2. Press Mail, Contacts, Calendars.
   

3. Press Add Account…
   

4. Press Other.
   

5. Under the Calendars heading, press Add CalDAV Account
   

6. Enter your CalDAV server URL (for Google it’s just “google.com”), username, password and a short description, then hit the Next button.
   

7. The iPhone will verify your information and then, if all goes well, your CalDAV calendar will appear in the Calendar app with the description you provided with the word CalDAV next to it in parentheses.
   

8. Now wait. It can take a few minutes for the iPhone to suck down the CalDAV data. I’m not sure why. But it should appear after a few minutes or so.

Navigating to this calendar will cause the iPhone to read the calendar data right from the server. If you have write access you will also be able to add, delete and modify events right on your iPhone and have the changes propagate to the server.

Multiple Calendar Subscriptions
UPDATE: See the end of the article for a better way to sync multiple Google calendars over CalDAV.

In addition to connecting to your main Google calendar it is also quite possible to connect to other CalDAV calendars to which you might want to be subscribed, though the process is hardly as automatic as the one above. Connecting to a single CalDAV calendar is easy for both you and the iPhone because the URL is simple and easy to predict, so the phone just does it for you. If, however, you want to connect to a shared calendar, the URL that you’ll need to supply to the iPhone is long and complicated and, unfortunately, must be manually entered.

To do so, you’ll probably want to start by getting that URL into the iPhone’s clipboard. There are lots of ways to do this. You can get it right from the Google calendar site (if it’s a Google calendar) using Mobile Safari. You could also send it to yourself in an email. The way I handle this is that I actually keep a spreadsheet on Google Docs that contains all my shared CalDAV URLs, that way I always have copy/paste access to them from the iPhone or from a computer. But however you do it, just get that URL into your clipboard, because you don’t want to type it by hand. Trust me.

The process for adding additional calendars follows the above steps almost exactly. The one exception is that for the Server entry in step 6 you must pass the long URL you just got into your clipboard. Just paste it right there into the field. After switching fields, it will present the Server text as just “google.com” again, but it should have the full URL stored away in its memory. Continue with the process and you should see the new calendar in the Calendar application as before.

Advanced Options
If a problem occurs during subscription an Advanced Settings button will appear.

This button also becomes available after the calendar has been set up. There are three options to set here:

1. Use SSL
   This allows you to configure your iPhone to connect via SSL, which is required by some servers. Google allows this option and may or may not require it. Generally it’s best to have this on if possible. Or at least more secure. If you’re having troubles, though, you can try toggling this setting.
2. Port
   This allows you to set the SSL port, in case your server uses something other than the default of 443.
3. Account URL
   This is the actual URL to your calendar. The one you pasted into the Server field. If something went wrong during that step you can check and fix it here.

In Practice
There are some advantages and disadvantages to this system. And while I really believe this is how any serious calendaring system should work — all your computers are clients that simply get the calendar data from the cloud — the implementation on the iPhone is not exactly mature.

For one, CalDAV calendars other than your main Google one are a major pain to add to the phone. Google provides an app for doing this on you desktop system, but for the iPhone it must all be done by hand. If you have many calendars it is a long and tedious process.

For two, receiving CalDAV data on your iPhone is, in my experience, very slow. Any changes made on the server will not be immediately seen by the iPhone. It can be several minutes after opening the Calendar app before you see the changes and there’s no indication that the sync is even taking place. This can be frustrating and misleading and requires you to always remember that there might be a change that’s coming that your iPhone just hasn’t seen yet.

Also, from time to time, though very rarely, calendars fail to load. I can’t blame this entirely on the iPhone, though. This happens to me even in the browser on my desktop system. It seems to be a problem with Google’s implementation and large numbers of calendars. Apparently Apple’s not the only one whose CalDAV implementation is immature.

Still, for me this system has worked pretty well thus far. I have a buttload of calendars to which I must stay subscribed, and which I must keep current. And I just don’t sync with my computer that often — plus, calendar changes are made at work — so that system was equally dodgy. My calendars don’t change that often either, so waiting for data to sync is less of an issue for me, though when there are major changes, getting everything re-synced really blows.

Overall, now that it’s in place, I’m very happy with CalDAV on my iPhone, though there is certainly room for improvement. I suspect it will only get better with time.

UPDATE: It looks like it did just get better. I’ve just discovered a better way to subscribe to multiple Google Calendars that I’m pretty sure wasn’t there when I set all this up a few months ago. It’s much easier and doesn’t require signing in to each calendar. Just subscribe to your main calendar as described in the above outlined steps, and then, on your iPhone, go to this page:
https://www.google.com/calendar/iphoneselect

Here you can select the calendars that will sync over your main Google account.

This is for Google accounts only. If you just have regular old CalDAV accounts that you want to sync with, manual entry will still be required.

UPDATE 2: This method seems to speed calendar syncing as well. I think the old method required the iPhone to log into each individual calendar, whereas this new method logs in once and syncs all the calendars with the one account. Much less work for the iPhone than before. Nice!

Final Cut 7 Garbled Image Display

This is my dog:

Garbled Dog

She is not normally purple and green and swirly colored.

After an hour or so mucking about, reinstalling the application, trashing prefs and otherwise performing the usual maneuvers, I decided to take my own medicine and reboot. Why I don’t just always do this first — like I tell everyone else to do — is beyond me. But sure enough, it worked.

Normal Dog

Ah! That’s better! Crazy mutt!

This Will Take a While

To wit: I have a very large folder — about 100GB — full of material that I intend to archive. That folder used to be called “BurnMe.” But I recently changed my archiving approach such that the “BurnMe” moniker seemed inappropriate. So I renamed “BurnMe” to “ArchiveMe.” My hope was that Time Machine would see that, yes, the folder had changed, but that its contents pointed to already existing files on disk, and that those files hadn’t changed and could thus be referenced with a hard link.

Unfortunately, Time Machine isn’t that smart. What it actually did was erase some older backups to make room, and then it indeed recopied the entire 100GB folder with the new name. Apparently, changing even the name of a file’s enclosing folder counts as a change to the file and will trigger a new backup copy to be created.

Deleting a Backup

My solution to this problem, unfortunately, will be to manage my Time Machine data a bit. It is possible to delete previous Time Machine backups by entering into the interface and right-clicking the file or folder you want to delete, then choosing to “Delete All Backups” of the selected file or folder. From now on I will need to be mindful of name changes to large folders, and be sure and delete the previous backups before (or perhaps after, depending on available space) I do so.

In any case, this is not a huge problem, but it is a minor inconvenience in a process that is meant to be almost entirely hands-off.