Cloud Files API custom status icons as an alternative to overlay icons

[Markus Kuhn]

Windows 10 version 1709 added a new “Cloud Files API”, for use by file synchronization services such as OneDrive:

https://docs.microsoft.com/en-us/windows/win32/cfapi/build-a-cloud-file-sync-engine

One of the things that caught my attention in the documentation of that API is this section:

“Shell integration

• State icons:
  • The cloud files API provides standardized, automatic hydration state icons shown in File Explorer and on the Windows desktop.
  • In addition to the standard Windows state icons used for hydration state, you can provide custom state icons for additional service-specific properties.
  • Replaces legacy icon overlay Shell extensions.”

An example of how to register such a “custom state icon” appears to be given in

https://github.com/microsoft/Windows-classic-samples/blob/master/Samples/CloudMirror/CloudMirror/CustomStateProvider.cpp

Microsoft clearly does not love the “legacy” overly-icon mechanism in Explorer very much:

https://devblogs.microsoft.com/oldnewthing/20091209-00/?p=15723

With its restriction to just 11 available icon slots, and the resulting frequent collisions with the icons of other “cloud file” applications, overlay icons have long been one of the main trouble spots for TortoiseSVN/GIT users. Would it be feasible to somehow use a tiny part of this new Cloud Files API and its ability to display custom status icons for files as an alternative to indicate the version-control status of working directory files and folders?

Markus

--

Markus Kuhn, Department of Computer Science and Technology
https://www.cl.cam.ac.uk/~mgk25/ | University of Cambridge

[Stefan]

unfortunately it's not possible to only use the state icons because those are only shown for a full cloud sync provider.

Meaning we'd have to implement such a provider, with a working copy being the "local" folder. But here's the problem: those "local" folder of cloud sync providers are not accessed directly by other applications but through a file system filter. And that causes a whole lot of problems for svn...