Warning Read more about the future of
wincsin issue #8.
wincs is a safe and idiomatic wrapper around the native Windows Cloud Filter API. The Cloud Filter API enables developers to implement their own remote file system from within user space. It is much like FUSE, although it contains many first-class Windows features that are only available through its API.
For example:
- Placeholder files
- Partial files
- Full files
- Pinned files
- Built into the native File Explorer
- Shown in the navigation pane at the uppermost level
- Group sync engines as siblings
- Register/unregister and connect/disconnect sync engines
- Register to the File Explorer
- Connect your file operation handlers
- Custom name tag and icon
- Automatic/custom hydration state icons
- Progress indication
- File dialog
- Inline next to file in the File Explorer
- A file toast if the user did not explicitly hydrate the placeholder
- Thumbnails and metadata
- Top-level context menu actions (even on Windows 11)
- Block specific apps from hydrating placeholders from Windows settings
- Automatically free space via Windows Storage Sense
- Monitor and filter file operations
- Declare a wide variety of supported file properties
- Files are cached to the disk (if set), allowing for offline access
- TODO: There is also a new API for custom UI, IStorageProviderStatusUISource
As of right now, the Cloud Filter API is used in production by OneDrive, Google Drive, Dropbox, and many other clients.
Below is a simple snippet of implementing a sync engine. For more, in-depth examples, please check out the examples directory.
// TODOUnfortunately, FUSE is only implemented for Unix-like operating systems. Luckily, there are numerous alternatives for implementing file systems on Windows, such as dokany or winfsp.
dokany has a Rust API and is accessible using safe code. However, it is fairly low-level and does not have the first-class capabilities supported by wincs. Read more here.
Unlike dokany, winfsp currently does not have a Rust API. Perhaps at some point it may, but even so, it is impossible to have the first-class features supported by wincs. Read more here.
Placeholders are internally NTFS sparse files and some reparse point magic. To put it simple, they are empty files that are meant to represent real files, although are not backed by any allocation unless requested. The way they work is heavily dependent on the sync engines' configuration. Know that if a process were to read the content of the placeholder, it would be "hydrated" (its file contents would be allocated). For more information, read here.
Of course, it is used by Microsoft's very own OneDrive Client. I have reported numerous issues and received quick feedback via the Microsoft Q&A. There are a lot of undocumented and unimplemented portions of the API, although they are not necessary for the features described here.
You are more than welcome to use it for local files, although the extra features may not suit your needs. It is recommended to instead use ProjFS, of which is also backed by Microsoft, but dedicated to "high-speed backing data stores."
If you are looking to contribute or want a deeper understanding of wincs, be sure to check out these resources:
- Build a Cloud Sync Engine that Supports Placeholder Files
- Integrate a Cloud Storage Provider
- Microsoft Q&A Containing "cfapi"
- Win32 API
- UWP API
- Not all classes in the
Windows.Storage.Providernamespace are used by cloud providers.
- Not all classes in the