In iOS 27, when you rename a file in the Files app on an iPhone with Apple Intelligence, Files recommends a name above the keyboard. Apple’s iOS 27 guide also describes Access Requests, an option for shared iCloud Drive links that lets other people with the link ask you to approve their access. Rename a […]

The post How to use Files name suggestions and Access Requests in iOS 27 appeared first on The Mac Observer.

One of our Macs kept filling up its SSD even though there isn’t supposed to be anything more stored on it. Photos is set to optimize its storage, and Messages is set to only keep messages for a year. It should be pretty much in a steady state, but we kept getting alerts from Mail that it couldn’t launch because there wasn’t enough free space. It’s an M4 MacBook Air used mostly for Web stuff, but somehow it felt as slow as the Intel one it had replaced.

I deleted unused apps and offloaded photos. Restarting sometimes helped, so I thought maybe it was an issue with Time Machine snapshots not being reclaimed promptly, which has been an issue before. But what data would even be changing so much to create large snapshots?

The problem kept getting worse, so I broke out OmniDiskSweeper. It didn’t find anything unusual, except it showed that the totals for the main folders added up to about 90 GB less than was reportedly used on SSD. Disk Utility showed that there were no snapshots taking up space. There must be real files but not ones that the app could see.

I relaunched OmniDiskSweeper using sudo, and it found a huge amount of stuff hidden in the root account: /private/var/root.

I had thought that wasn’t really used except when running Terminal from macOS Recovery. But apparently various daemons store all kinds of stuff there now. The /private/var/root/Library/Logs folder alone was using 74 GB, and there were also several multi-GB cache folders.

The logs were almost entirely from RTCReporting, and I’m not the only one to run into this.

I deleted the files using OmniDiskSweeper, but that didn’t help. It turns out that by default it moves files to the trash, and I guess since it was running under sudo this meant the invisible trash folder for the root account. It’s better to hold down the Option key to Delete Immediately.

After deleting the files and restarting the Mac, the free space looked right at first but then steadily dropped. Pretty soon there were again 5 GB of RTCReporting logs with the Mac just sitting there. I started using sudo du -h -d 2 /private/var/root/ to track how the sizes were changing. Within a day it was back up to 27 GB.

Activity Monitor showed that rtcreportingd and fileproviderd were each using almost 100% CPU constantly. I immediately suspected Dropbox because it had been working poorly on this Mac for a year or so. It wouldn’t keep files offline and constantly seemed to be syncing even when files weren’t changing. Sure enough, turning off Dropbox stopped the CPU use and the ballooning log files.

This was our last Mac still using Dropbox, so it seemed time to migrate it to iCloud Drive. The syncing problems ended up not being limited to keeping files offline. It couldn’t even reliably download most of them from the cloud to move them out of the Dropbox folder, instead reporting I/O errors for most files. And the files that I did move to the Documents folder never synced that deletion up to the cloud. I ended up just downloading the whole folder from the Web interface. iCloud Drive uploaded everything quickly and then settled into a state of no CPU use.

Previously:

• Sunsetting Maestral
• When Dropbox Spawns a Million Folders
• Tahoe Free Space Problems
• Fixing “Optimize Storage”
• Update on Cloud File Provider Extensions

I have a Mac Studio M2 Max with 32 GB of RAM and a 1 TB SSD in front of me. While not the most powerful personal computer you can purchase today, it is among the most computationally capable ever made—a vastly capable machine. So why do I have to wait for typing to catch up with me and see a rainbow spinner on the regular?

I’ll tell you why: iCloud Drive and Spotlight. Apple lacks any transparency about how iCloud Drive works or fails. The same is true of Spotlight. These big black boxes churn away, performing a million billion operations a day, and we don’t know exactly what they do. That’s not me being conspiratorial: I honestly don’t care what’s happening under the hood—until it breaks. Without diagnostic tools, even someone like me, ostensibly an expert, can be completely at a loss and waste many hours.

I wrote “Cloudy with a Chance of Insanity: Unsticking iCloud Drive” for TidBITS back in October 2023 about a multi-month odyssey with Apple technical support in trying to dislodge unsyncable files.¹ That problem has barely surfaced since—an 80K file will sometimes get stuck for a while—and I thought Apple might have really solved syncing, at least as exhibited on my Mac. I receive dramatically fewer emails about iCloud Drive than I used to, which is another data point.

But Mr. Edge Case here can always find a way to break something.² I’ve been working on a large manuscript for my upcoming book, Flong Time, No See, a revised and expanded collection of researched articles I’ve written about printing and type history over the last several years.³ I pasted in text that was typically copied from Web pages, and wound up with over 250 footnotes.

While putting together the files for this book, Apple released its Creator Studio system, and shipped Pages 15. After having no problems, I dutifully switched over. This was months ago, and as I continued to work on this reasonably large file—weighing it at about 60,000 words now—everything seemed fine.

A few weeks ago, however, I started to experience system slowdowns. Pages was taking up 12 GB of system memory! System load went through the roof! CPU consumption was outlandish! All signs pointed to corespotlightd, a long-time enemy of performance. That daemon handles background indexing for Spotlight, and the slightest thing wrong in a file or directory, or perhaps due to mild corruption in its underlying files, turns it into a rampaging beast that eats processor cycles like I consume potato chips.⁴

There’s a well-known procedure for killing this beast, though another is spawned from its remains: stop the index, delete the index files, restart, and re-enable indexing. From the Terminal, use these commands. Make a backup before proceeding. Take extreme care with rm -rf, as a misstep in entering or copying can wipe out files!

 sudo mdutil -a -i off
 rm -rf ~/Library/Metadata/CoreSpotlight

You can use Restart from the Apple Menu while holding down the Option key (to avoid being asked), or you can take a shortcut from Terminal, assuming you have ensured all files are saved:

 sudo reboot

After your Mac restarts, go back to the Terminal and re-enable indexing:

 sudo mdutil -a -i on

For many (perhaps most) people, this solves the problem. For me, it just delayed it. With some isolation using System Settings: Spotlight: Search Privacy, I added specific folders, such as mail archives, since that seemed like it might be part of the problem.

One piece of advice I found suggested that if I thought Pages was the problem, I should exclude the iCloud Drive path containing Pages files. Fine! I clicked the plus icon in Search Privacy, pressed Command-Shift-G to bring up the path dialog, entered ~/Library/Mobile Documents/com~apple~Pages/, and clicked Choose. This seemed to work for a while, then nothing availed.

Finally, after analyzing logs and caches, the culprit was clear. It was not that large a Pages file: every time I saved, Spotlight’s worker bee was performing excessive re-indexing that consumed gigabytes and one or more processor cores. Moving the file to a local directory (in my Documents folder) while editing eliminated the problem. It also freed up space, as the temporary Spotlight indexes and Time Machine snapshots had become absurdly large.

What could Apple have done to help here? This is where I would hope machine learning, coupled with some interactive code- and system-expertise bots, could help:

• Note that a system component is acting well outside known parameters.
• Identify CPU usage that is tied to Apple-owned processes.
• Provide a troubleshooting tool, even suggesting it in notifications.
• Create human-readable logs that don’t require system administrator knowledge to interpret.

In the case I describe above, an Apple-created daemon was rampaging out of control due to a single identifiable file!—cascading into other problems. It should be solvable by Apple. The fact that we have more power under the hood by orders of magnitude in the past, coupled with neural cores in the CPU packages, just makes this even more embarrassing. Solve Siri, Apple, yes, but real transparency and troubleshooting in macOS would also make a big difference.

[Got a question for the column? You can email glenn@sixcolors.com or use /glenn in our subscriber-only Discord community.]