I was the Tech Chair (aka Zoom Facilitator) at today’s Silver Tongued Cats hybrid meeting; I’ve done it before, and it’s usually easy to get set up.

Today, though, when I plugged in the USB-C to HDMI and USB-A minidock I needed to connect my webcam to my computer, I got a prompt asking me whether it was OK for the minidock to talk to the computer. I clicked “Yes” (or so I thought) and I went about the rest of the meeting setup (starting Zoom, calling it from the conference room phone for audio, and so forth). The HDMI connection worked fine, but Zoom couldn’t see my webcam.

I was puzzled. I was more puzzled when I fired up System Information and it didn’t even show the minidock on the USB device tree.

I thought we’d have to go through the meeting without the webcam (fortunately, our Toastmaster had set up his phone to show video of the lectern) until I plugged a power brick into the other USB-C port on the computer. Suddenly, I got another prompt asking about the USB minidock; this time, I was very careful to answer “yes”, and as if by magic, Zoom saw the webcam and all was well.

I guess I have to be more careful about what I click.

I kept looking for good ways to solve my problem of yesterday. One idea which came to mind was editing /etc/profile to be better behaved with regards to leaving my changes to the PATH alone, but I expected that my changes would be lost every time I installed a new version of Mac OS, so I didn’t try it.

But then Apple released Mac OS 13.5 with significant security fixes, and I needed to install it. I changed /etc/profile before doing the installation, and I was delighted to find my changes were still there after the update, so that may be a viable strategy.

I also looked at my Ubuntu systems to see what they did in /etc/profile – they’re even more brutal than Mac OS. Mac OS puts its preferred directories at the front of the PATH so they’re seen before whatever was in the PATH when /etc/profile is read; Ubuntu simply overwrites the PATH with its own version.

Oh, well; who said using a computer would be easy?

They say you never know if you have a real backup until you try to use it. They’re right.

TL;DR

• Don’t encrypt your drive until you’ve restored your data
• Don’t exclude things from Time Machine backup

The details

I sent my 2017 MacBook Pro to Apple because the keyboard was acting up. And as long as I was at the Genius Bar, I thought it’d be a good time to mention a weird problem I’d had when using Screen Mirroring on my Apple TV (moving the cursor would reveal things lower in z-order – it was weird); the Genius duly wrote that down and sent my machine to the depot for repair.

A few days later, the machine was back in my hands; not only had they replaced the keyboard and the top case (as I’d expected), but they also had replaced a few other parts – and they’d either wiped or replaced the SSD, so I had a virgin installation of Mac OS and none of my data. I booted up the machine, and, for security, told it to turn on FileVault to encrypt the SSD; then I set about restoring my data.

Plan A

I had multiple backups: Time Machine, a bootable clone drive (made with SuperDuper!), and Backblaze for offsite backup. I thought that the easiest solution would be to reboot from the clone drive and restore to the SSD, so I did exactly that.

The restore went fine, except for one small problem – SuperDuper! was unable to update the PreBoot environment. When I tried to boot from the SSD, I got a blinking folder with a question mark, which meant that the system couldn’t find the startup disk. I booted from the clone again and used System Preferences to set the startup disk to the SSD; this time, instead of the question mark, I was asked for a disk password…which, of course, I didn’t have.

Back to the clone, where I could easily mount the SSD and see its contents. Searching gave me this thread, but I couldn’t figure out how to apply the hints to my environment, so it was time for Plan B.

Plan B

I booted the “Install High Sierra” USB stick I’d kept around from last year and erased the SSD. Then I restored from my Time Machine backup. Many hours later, I was able to boot the SSD, and all seemed well.

Except…my desktop background was wrong. And my Dropbox folder was empty (though that was easy to fix by firing up Dropbox). And when I looked further, I realized that I didn’t have any of my photos, nor my iTunes library, nor my DevonThink databases. It was as if they’d never existed. But they were on the clone drive. Hmmm….

Plan C

I booted the clone and fired up SuperDuper! again. And, again, I restored the SSD from the clone, using “Smart Copy”, which found 150GB already on the SSD, and about 200GB of data that needed to be copied.

This time, when I booted the SSD, all was well – I had all of my data.

I opened Time Machine Preferences and discovered that I’d excluded my iTunes library, my Pictures folder, and my DevonThink databases from being backed up in order to save space on the drive in the Time Capsule that I was sharing among several computers. Oops. Especially since I’d stopped sharing a Time Capsule months ago and was backing up to a directly-attached 4TB drive, with plenty of space.

Conclusion

All seems to be well; I’ve removed the exclusions from Time Machine and it’s busily backing up everything now.

I haven’t checked to see if the Apple TV screen mirroring problem has been fixed – I guess I should find out, though.

I think I’ll wait a few days after Mojave ships before I upgrade; I really don’t want to go through this again any time soon!

For quite a while, I’ve noticed an odd pattern whenever I open Activity Monitor on my Mac – something was writing to my disk every 2 or 3 seconds, at a peak rate of 4.5MB/second. Over time, the total data written would climb into the terabytes (far exceeding the total data read from the disk) – but my free disk space wouldn’t diminish. Looking at the system logs didn’t enlighten me, and nothing was obvious in Activity Monitor. I’d shake my head and ignore it.

This morning, I noticed the pattern again, right after rebooting the system, and I decided to try to find out what was causing the I/O.

First step: ask Google. In particular, I asked it what process is doing i/o mac and found many potentially-useful pages. The one I chose to pursue was an Ask Different question: Which process is periodically writing to the disk? because the screenshot in the question matched mine almost exactly.

The accepted answer to the question led me to try iotop(1), but I kept getting errors from DTrace (even though I ran it as root). So I tried what looked like the next best answer, using fs_usage(1):

sudo fs_usage -w -f filesys -e grep  \
   | grep -i ' write ' > /tmp/iouse.txt

and then looking at iouse.txt showed me that a process named lssave was doing a ton of I/O. A quick Google for lssave led me to this Stack Overflow page, which led me to this macosxhints discussion, which made it clear that I needed to rebuild my Launch Services database. I used Onyx to do the job, and voilà – no drumbeat of writes!