Placeholders have returned, without the flaws of Microsoft’s first implementation.

OneDrive placeholders are back. A new OneDrive client is available for the latest Windows 10 Insider build, and it brings back seamless integration with OneDrive cloud storage under the name "OneDrive Files On Demand."

With cloud storage services, it's very easy to have large amounts of storage and data "in the cloud" that you don't necessarily have room for locally. The traditional solution has been some kind of selective sync; some folders are nominated to be stored locally, while others are visible only through the service provider's Web interface. While this addresses immediate size constraints—it means that your hundreds of gigabytes of cloud files won't overflow your laptop's paltry 128GB SSD—it typically represents an awkward usability trade-off. Those files that aren't synchronized locally become invisible to the operating system, so you can't browse and manage them in Explorer, and neither can you open them directly in your applications.

Windows 8.1 was Microsoft's first attempt at solving this, introducing the concept of placeholder files. Placeholders were small stub files that were stored locally and that stood in as a proxy for the real file in the cloud. With placeholders, Explorer and file save/open dialogs can show you every cloud file, so you never need to resort to opening your browser to manage your files. The theory was that when you opened a placeholder, the system would seamlessly fetch the file from the cloud, store it locally, and then open the real file.

Indeed, superficially, this is how the placeholders worked in Windows 8.1. But there were many wrinkles and problems. The chief problem is that the syncing and retrieval of placeholders was handled by Explorer and the OneDrive client. Clicking a placeholder in Explorer did the right thing, but in other contexts—for example, opening a file at the command line or, indeed, any attempt to open a file with the Win32 CreateFile() API—attempts to use the file failed. Applications either failed to open the file entirely or opened the placeholder itself rather than the real data, depending on how exactly they used the API.

As well as this technical issue, the Windows 8.1 placeholders had some usability problems. Explorer used icon overlays (little sub-icons appearing on top of the regular icons for each file) to indicate whether a file was stored locally or only available in the cloud. This is important to show because, for obvious reasons, files that are only available in the cloud require a network connection before they can be used. But Explorer's icon overlays are problematic; only a limited number of them can be registered, for example. That means, if you installed other applications that used lots of overlays, the OneDrive overlays could be clobbered.

What’s different

The new Windows 10 placeholders address both of these problems. First, the placeholders are now handled using a mix of a file system driver and the OneDrive client. Operating at this lower level means that all actions on the placeholders—whether they be through Explorer, the command line, or the Windows API itself—can cause the files to be retrieved. Second, Microsoft is using a different kind of status overlay in Explorer. The new overlay doesn't use icon overlays; instead, it puts the synchronization status in the filename field (or, in Explorer's details view, in an entirely separate column). This means that there's no risk of the overlays becoming broken; it also means that they're larger and more immediately visible.

With this new system, the OneDrive placeholders should be both substantially more reliable than they were in Windows 8.1, as well as somewhat clearer about which files are local and which aren't. Files can be in one of three states: always-local (for the most important files), demand-synced and available offline (for files that have been downloaded), and demand-synced but not available (for files that only exist in the cloud).

Cursory examination suggests the new system works well and is much more robust and compatible than the Windows 8.1 approach.