It’s uncommon for people to want to print TidBITS issues, so I was surprised when Lauri Reinhardt, who helps us with support, forwarded me a message from a reader asking if there was a way to print the email issue of TidBITS with all the images. Neither of us had ever tried to do such a thing, but the reader was entirely correct: printing a TidBITS issue or exporting it to PDF resulted in blank boxes in place of the images. 

Tinkering with Mail’s Protect Mail Activity setting made no difference, and the images showed up fine in the message itself—it wasn’t related to loading remote content. Even more confusing was the fact that Mimestream, which I use with Gmail, suffered from the same problem, but only in macOS 12 Monterey, not in macOS 13 Ventura. Printing from Gmail’s Web interface also worked fine.

A look at the raw source of our issues revealed a smoking gun right away: a loading="lazy" attribute for every IMG tag in articles. The sponsor banners at the top of the issue lacked that attribute, and they appeared in PDFs fine. Curious, I turned to Mimestream’s developer, Neil Jhaveri, who used to work on Mail at Apple. He said that Mail generates an offscreen web view, waits for the “load” part of the document to arrive, and then “prints.” But loading="lazy" causes images to load only when scrolled into view, which never happens with printing. Mimestream shared the problem, at least in Monterey, because it uses WebKit for printing, just like Mail. Neil recommended dropping the loading="lazy" attribute because he didn’t think images (at least those with width and height attributes) would block the page from rendering until loaded anyway.

During these conversations, Lauri stumbled upon a workaround that makes sense in the context of Neil’s explanation. She postulated that perhaps the images were too large to load, so she tried shrinking them with the Scaling option in the Print dialog, which caused at least some images to display. I did testing and found that if I changed the scaling percentage to 99%, some images would load—but they’d be fuzzy—and others would remain blank. However, if I changed the scaling percentage more seriously, such as to 87%, and then scrolled through the entire document preview, all images would appear crisply in the resulting PDF, even if I later returned the scaling to 100%. Presumably, asking the Print dialog to scale the output forced WebKit to load all the images, allowing them to appear.

When I asked our developer Eli Van Zoeren to remove that loading="lazy" attribute from the IMG tags, he noted that WordPress inserted it automatically, so he added a filter to remove it from the email versions of our issues. (His code adds the sponsor banners to the issue separately, which is why they lack that attribute.) I was excited to test the fix with the next week’s issue, only to be disappointed to discover that the problem hadn’t gone away. It turned out that, after Eli filtered out loading="lazy", WordPress replaced it with a similar-sounding attribute decoding="async". After another round of Whack-an-Attribute, the problem disappeared for good.

So, while I don’t recommend printing TidBITS issues—we don’t format them for print, and they’ll consume quite a bit of paper—you’ll at least see the images now. Interestingly, both screenshots above have extra blank pages at the end. I don’t know why Mail adds them, but I recommend removing them. Choose File > Export to PDF, open the file in Preview, select the blank pages (and any other unnecessary pages) in the sidebar, and delete them before printing.

I very much doubt that many people were affected by this problem, but at least one TidBITS reader will be happier, and with luck, others who run into a similar problem will find this article and figure out how to solve it more quickly.

Over the last year, cloud storage services Box, Dropbox, Google Drive, and Microsoft OneDrive—and probably others—have migrated from custom kernel extensions to Apple’s new-ish File Provider extension. It provides an Apple-approved framework for integrating remote files into macOS and displaying them in the Finder. I touched on this move a year ago in “Cloud Storage Forecast Unsettled, with Possible Storms” (4 February 2022).

The File Provider extension first appeared in macOS 12.1 Monterey, though Apple’s Developer site suggests that it may have subsequently been made available in macOS 10.15 Catalina. Earlier versions of macOS don’t support it, so nothing changes for those running older systems for now. The cloud storage services will likely pull support for older systems at some point, but there’s no telling when that will happen. (Everything I say below I’ve tested in macOS 13.2.1 Ventura—it’s possible, even likely, that some details are different in Monterey.)

The cloud storage companies undoubtedly felt they had little choice about adopting the File Provider extension because Apple said it would be deprecating kernel extensions at some point. That hasn’t happened yet, but Apple often gives developers several years to get with the program.

My understanding is that Box, Google, and Microsoft have migrated their Mac users to the File Provider approach, whereas Dropbox—probably the most popular among everyday Mac users—has only recently started to encourage those outside its beta program to switch (while others are still being asked to join the beta). It can be hard to tell since cloud storage providers often roll out changes over time or to subsets of customers to test user response, identify concerns, and reduce support loads. Some Dropbox users even report one Mac being upgraded to the new File Provider approach, while others continue to use the kernel extension.

Although it’s good to have cloud storage integrated into macOS in a coherent fashion, the switch to Apple’s File Provider extension brings with it two key changes that will require adjustments in how you work.

The first change is where local files are stored. All cloud-storage services must now store their files in ~/Library/CloudStorage. (That’s in your home folder’s Library folder, which is non-trivial to access for most users since the Library folder is hidden by default.) From a consistency and coherency point of view, the new standard location is a good thing, since users don’t have to keep track of where each individual service might have its files. However, just as when Mac OS X introduced the home folder and its now-canonical subfolders (Desktop, Documents, Library, Movies, Music, and so on), the loss of flexibility will create pain points for some users.

The second change revolves around whether the files exist both locally and online (“offline” or “pinned”) or just online (“online-only”). Both have advantages and disadvantages:

• Offline files are stored both in the cloud and on the local drive for quick access. However, they consume local storage space, which may be a problem if you’re low on free space. There’s no visible indication that a file is offline.
• Online-only files exist locally only as icon placeholders until they’re opened—they have little cloud icons next to their names in the Finder. This approach saves space, but may suffer from loading delays with large files or slow connections. Of course, online-only files aren’t available if you lack connectivity.
  

After you first migrate a cloud storage service to the File Provider approach, assume that all your files and folders are online-only. That might not be the case—you can tell by looking for the little cloud icons—but such files, as I’ll discuss below, can’t be viewed using Quick Look, indexed by Spotlight, or backed up by Time Machine and other backup apps.

You can control the state of any file or folder. If you click the cloud icon next to a file or folder name, that initiates a download, turning it from online-only to offline. Control-click an offline file and you’ll find commands for downloading files (making them offline) or removing their downloads (making them online-only). Dropbox (below left) relies on Make Available Offline and Make Online-Only commands in the Quick Actions section at the bottom of the pop-up menu. Google Drive (below right) puts Download Now and Remove Download commands at the top of the menu; it has Quick Actions as well.

Of course, opening an online-only file in an app also downloads it. It’s possible that a third-party app would be unhappy when fed a file that hasn’t yet been downloaded; if you get an error, make sure the file is available offline and try again.

To be clear, this distinction between offline and online-only files isn’t new or unique to the File Provider extension. All the cloud storage services have provided ways to specify which files or folders were kept locally and which existed only online. The details and implications varied somewhat, but the concept was the same.

Let’s look at some of the impacts of these File Provider changes. I focus on Dropbox and Google Drive below because those are the services I use regularly, but Box and OneDrive should be similar in most cases.

Sidebar Locations May Change

The File Provider approach brings cloud storage services into parity with one another and with other forms of storage in macOS. As a result, Apple has decreed that they appear by default in the Finder window sidebar under Locations. You can even turn them all on and off in Finder > Settings/Preferences > Sidebar.

The new spot may cause some minor confusion, if you previously kept the Locations item closed in the sidebar or regularly accessed Dropbox or Google Drive, for instance, from sidebar items under Favorites. However, you can drag any cloud storage service’s sidebar item from Locations to Favorites or even have them in both Locations and Favorites.

This change is minor and easily tweaked however you prefer, but I mention it first because you should click any sidebar items you have and make sure they still work and, more importantly, still work properly.

Look Out for Disconnected Local Folders

Why might a sidebar item not go to the right place? When a cloud storage service switches from its custom kernel extension to the File Provider extension, the location of its local folder moves from wherever you had it to ~/Library/CloudStorage. Or at least that’s the goal.

(As a quick reminder, if you don’t see the Library folder in your home folder, hold Option and click the Go menu, which makes Library visible in the menu. Or, with the home folder open, choose View > Show View Options and select Show Library Folder to make it always visible.)

Some users, including us, have experienced situations where the local folder doesn’t move but becomes disconnected from the service. Since the cloud storage service will immediately sync to the new location, you can end up with two Dropbox folders, for instance, one at ~/Dropbox and another at ~/Library/CloudStorage/Dropbox.

The cloud storage services somewhat muddy the waters by creating what looks like an alias (really a symlink) in their old locations to maintain continuity for users. But is that Dropbox folder in your home folder a symlink or a disconnected local folder? Check by opening Terminal and typing ls -l (if you’re not already in your home folder, use the cd command first). As you can see below, I now have Dropbox and Google Drive folder symlinks in my home folder. Notice how the symlinks have an l in the leftmost column, whereas directories like Downloads and Library start with a d and the Dropbox Demo Alias I made for illustration has a -.

Verify your findings by copying a new file into the local folder and then checking on the cloud storage service’s website to see if it was uploaded.

If you do have a disconnected local folder, you’ll have to do some spot checks to make sure everything in it also exists in the online version. I do that by using List View in the Finder, sorting by Date Modified, and then expanding the folders and checking that the most recent files are in both places. When I ran into this with Google Drive, I had only a handful of files that were out of sync, but if you see a lot of differences, consider using synchronization software like ChronoSync to figure out which files need to be moved.

Be sure to delete the disconnected local folder once you’re done to avoid accidentally using it later. If the service doesn’t subsequently create a symlink automatically for you, I recommend making one with these steps:

1. In Terminal, type cd and press Return to ensure you’re in your home folder.
2. Type ln -s  (leave a space after the s).
3. In the Finder, choose Go > Go to Folder, type ~/Library/CloudStorage, and press Return to open that folder.
   
4. Drag the cloud storage service folder—Dropbox or Google Drive, say—from the Finder to the Terminal window to insert its path. This approach is necessary because at least Google Drive actually has a different name than what you see. Press Return to create the symlink.
   

References to Local Files and Folders May Break

In an ideal world, if the cloud storage service created an alias of its relocated local folder from ~/Library/CloudStorage to wherever you had it previously, any aliases or other references to files or folders in that folder should continue to work.

However, that’s not always the case, especially if you had to clean up a disconnected local folder. If you deleted your disconnected local folder, as I recommend, any aliases that pointed to files or folders in it will break. That’s good, since then you know to recreate them.

Similarly, some apps like BBEdit, Keyboard Maestro, and Transmit can optionally store support files in cloud storage as a way of syncing settings and other data between Macs. In the ideal world described above, everything should keep working, and that was my experience with my most recent Dropbox migration with a few Keyboard Maestro macros that reference Automator workflows and BBEdit text filters that I had stored in Dropbox.

However, there are no guarantees that references to files will all resolve to the new locations, and in the case of apps that use cloud storage for syncing settings, you may not even notice immediately. For hints about which apps might be leveraging cloud storage for syncing, look through your various cloud storage folders, Dropbox in particular.

External Drive Support Disappears, Except for OneDrive

The most significant limitation of the new File Provider approach is that ~/Library/CloudStorage is located on your internal drive. For those with terabytes of files in a cloud storage service, that’s a huge problem.

Previously, you could specify where you wanted your cloud storage service’s local folder to live, making it easy to locate it on a large external drive. With the File Provider approach, that’s no longer possible. Or so Box, Dropbox, and Google are saying at the moment, although Microsoft has worked around the limitation with OneDrive by separating the “sync root” (which has to remain in ~/Library/CloudStorage) from the cache, which can live on an external drive.

Users are up in arms about this change, particularly those who use Dropbox to keep audio or video processing workstations updated with very large shared files.

The news isn’t entirely bad. On 17 February 2023, Dropbox posted a note in a long and vitriolic thread about the loss of external drive support, saying that the company was working on a solution and users who have their Dropbox folder on an external drive wouldn’t be upgraded in the meantime.

If waiting for Dropbox isn’t an option, consider the open-source Dropbox client Maestral. It allows you to locate your Dropbox folder anywhere you want, including on an external drive. Maestral relies on the public Dropbox API, which prevents it from transferring only the parts of a file that change from save to save—a binary diff. Instead, Maestral has to transfer entire files, which will be slower and use more bandwidth. Maestral doesn’t count toward Dropbox’s three-device limit for basic accounts (see “Dropbox Limits Free Accounts to Three Devices,” 14 March 2019).

There might be another workaround, which is to relocate your entire home folder to an external drive. Control-click a user in System Settings/Preferences > Users & Groups to access the Home Directory field. Don’t even think about doing this—even with a test account—unless you’re technically adept and have made multiple backups first.

Even assuming that relocating the home folder to an external drive works as desired, there are negatives. It won’t work well for laptops, of course, and if you don’t wish to shell out for an expensive SSD, you’ll suffer from the slower performance of a hard drive. In addition, there’s some online discussion about how installing macOS updates while logged into an account located on an external drive can cause problems; the advice seems to be to update macOS while using an administrator account on the internal drive. If you try this, let us know in the comments how it works.

For thrill-seekers who have the necessary technical chops and excellent backups, there are other options you could try—again, let us know in the comments if either of these works:

• Dropbox: If you’ve already migrated Dropbox to the File Provider approach, a user posted a possible workaround in another Dropbox Community thread. It involves using a symlink to point at the Dropbox folder on an external drive, similar to what Microsoft does with OneDrive. In the recent past, Dropbox hasn’t supported symlinks to items on external drives, but perhaps that’s changed.

• Google Drive: Although Google Drive claims you cannot change its location, a May 2022 discussion in the Google Drive Help forum recommends using the Unix touch command to create a file in a particular location. The suggestion is that doing so causes the Google Drive app to revert to pre-File Provider behavior.

Dragging Files Moves Rather Than Copies

Some of the cloud storage services used their kernel extensions to treat their local folder as a separate volume. The practical upshot was that dragging a file to or from the service’s local folder resulted in a copy action, leaving the original in place and making a new version in the destination location. Reasonable people can differ about whether this was the right or wrong thing to do, but regardless, it’s what users became accustomed to.

With the File Provider approach, all the cloud storage services are essentially folders on the internal drive, not separate volumes, so dragging a file from your Desktop to your Dropbox folder moves the file rather than copying it, as does dragging a file from Google Drive to the Desktop.

That’s an important change because the services also have to maintain an online copy of the file, so at least Dropbox and Google Drive interpret moving a file to another folder in the Finder as a deletion of the online version, putting the moved file in the service’s online trash. Both also alert you to what’s happening, and you can turn the alerts off.

Trashing Retains Online Copies, but Local Behavior May Vary

So what happens when you use the Finder to delete a file from a cloud storage service? It varies, and I can speak only to what happens with Dropbox and Google Drive, but I suspect Box and OneDrive will be similar to one or the other of these approaches. If that’s not the case, please contribute additional details in the comments.

With Dropbox, you’ll see different behavior based on whether the file is offline or online-only. When you trash an offline file, it simply moves to the Trash like any other file in the Finder. You can put it back, move it to another location, or delete it permanently by emptying the Trash. However, when you delete an online-only file, Dropbox alerts you that the file will be deleted immediately (below left). When Dropbox says that you can’t undo the action, it means that it’s not putting the file in the Mac’s Trash, so Command-Z won’t work. However, deleting either type of file moves it to the Deleted Files collection on the Dropbox website, where it stays for 30 days before being deleted permanently (below right).

Google Drive has no such distinction. When you delete any file in Google Drive, offline or online-only, it moves into the Mac’s Trash like any other file. You can press Command-Z to undo the deletion. Online-only files retain their cloud icons while in the Trash. As with Dropbox, Google Drive also puts deleted files in its online trash, as you can see with the two ChartOfAccounts files I’ve deleted in the screenshots below. Again, deleted files remain available online for 30 days.

Searches May Work Poorly for Cloud-Based Content

The offline/online-only state of files has implications for searching. Unsurprisingly, if a file is online-only, there’s no way Spotlight can index its content. However, filename searches in Finder windows should work, as should searches in third-party utilities like EasyFind or Find Any File.

Google Drive offers an easy workaround for content searches. You can bring up a custom Google Drive search dialog in the Finder; the default keyboard shortcut is Command-Option-G. It runs the search on Google Drive on the Web, which can easily search the full content of your files stored in Google Drive. It also finds content in Google Docs and Google Sheets, which wouldn’t ever show up in Spotlight, since they exist on local drives only as pointers to the online data.

Backups Work, But…

By now, you can see that online-only files don’t really exist on your Mac. That means Time Machine and other backup solutions cannot back them up. It appears as though all Dropbox folders appear in Time Machine, though only offline files show up in them. In contrast, Google Drive’s folders only appear if they contain offline files. Similarly, Backblaze sees and backs up offline files in ~/Library/CloudStorage, but it doesn’t know about online-only files at all. That’s why there are only two files in the folder shown below.

As I noted at the top, you should assume that everything in a cloud storage service is online-only to start and thus isn’t being backed up separately. That might not concern you—after all, the data all exists in the cloud. However, if you’re sharing folders with other people, it’s possible for them to delete files or entire folders accidentally (or maliciously), thus removing them from everyone in the share group. In theory, they should be available in an online trash or Deleted Files collection, but you may not want to bet on that. A local backup made with Time Machine, Backblaze, Super Duper, or any other app can protect you from such mistakes.

Such things happen—Tonya recently ran into a situation where someone in her workgroup inadvertently deleted an important Box folder containing weeks of work. There might have been other ways of recovering it, but copying from her Time Machine backup was quick and didn’t require opening a ticket with IT support.

Therefore, assuming you have sufficient disk space, I recommend downloading your entire cloud storage data store, at least temporarily. Bring everything down and let Time Machine and your other backup systems make a copy. Then, if you want to recover the disk space, reset folders you don’t need to online-only. New files you create will be offline because you’re working on them, so they’ll automatically get into the backups.

Phew! When I started this article, I thought it would be a fairly short explanation of how the Dropbox folder had moved after migrating to the new File Provider extension. Three days of research and testing later, I think I’ve wrapped my head around all the details. But perhaps not! If you still have questions, ask them in the comments.