Introduction
Welcome to CBFS Sync, a suite of components enabling seamless synchronization between local files and cloud storages or other remote repositories.
Add OneDrive-style, bidirectional synchronization to your applications with CBFS Sync. The event-driven design of CBFS Sync provides an intuitive way to handle operations performed on local files and folders. When remote changes are made, use the included methods to notify the local system.
The CBSync component builds on industry-standard technologies, including the Cloud Filter API on Windows, FUSE on Linux, and File Provider on macOS. CBSync reduces development time and improves the user experience by providing a single API. All icons and indicators visible to the user are presented by the operating system, ensuring a native experience.
The choice of the remote storage is entirely up to you. Whether your data are stored on a popular cloud storage service, a custom file server, or anywhere else, CBFS Sync provides a simple API to facilitate synchronization. CBFS Sync handles integration with the OS, while your code is responsible for handling events and transferring data between local and remote systems. Because your code interacts with the backend, you can also decide to make the synchronization one-way or bidirectional.
lib\net40\callback.CBFSSync.dll is designed for use in .NET Framework 4.0 and up. This library maintains a familiar API in line with previous versions of the product.
-
lib\net6.0\callback.CBFSSync.dll is designed for use in .NET 6 and up. The .NET 6 library maintains the same API as the .NET Framework version of the library and can be used in projects that are based on .NET 6 and later.
lib\netstandard2.0\callback.CBFSSync.dll is designed for use in .NET Standard 2.0 and up. The .NET Standard library maintains the same API as the .NET Framework version of the library and can be used in projects that are based on .NET Core and .NET 5 and later.
CBSync | The CBSync component enables seamless synchronization between local files and cloud storages or other remote repositories. |
Additional Information
You will always find the latest information about CBFS Sync at our web site: www.callback.com. We offer free, fully-functional 30-day trials for all of our products, and our technical support staff are happy to answer any questions you may have during your evaluation.
Please direct all technical questions to support@callback.com. To help support technicians assist you as quickly as possible, please provide a detailed and accurate description of your problem, the results you expected, and the results that you received while using our product. For questions about licensing and pricing, and all other general inquiries, please contact sales@callback.com.
Thank You!
Thank you for choosing CBFS Sync for your development needs. We realize that you have a choice among development tools, and that by choosing us you are counting on us to be a key component in your business. We work around the clock to provide you with ongoing enhancements, support, and innovative products; and we will always do our best to exceed your expectations!
Deployment
The user-mode library comes in two pieces, both of which must be deployed along with the application:
- A .NET assembly (managed), named callback.cbfssync.dll (or callback.cbfssync.NetStd.dll, for .NET Standard).
- A native dynamic library (unmanaged), named cbfssync24.dll, available for both 32-bit (x86) and 64-bit (x64, ARM64) processor architectures.
When deploying the application, copy both the .NET assembly and the native library to the target system and place them next to the application's executable file (on Windows, it has the .exe extension).
Windows Only:
The .NET assembly may alternatively be deployed to the Global Assembly Cache (GAC).
Alternatively, the native dynamic library may be placed into one of directories, the paths to which are contained in the
- Windows: PATH environment variable, such as C:\Windows\System32 (or C:\Windows\SysWOW64 when deploying a 32-bit application on a 64-bit Windows system)
- Linux: LD_LIBRARY_PATH environment variable
- macOS: DYLD_LIBRARY_PATH environment variable
NuGet Notes
After the NuGet package is added to a project, both the managed .NET assembly and the unmanaged native library will be copied to the project's output directory anytime the project is built. However, the exact files copied to the output directory for the native library will vary based on the project type:
- For .NET Core projects, a runtimes directory will be created in the output directory (if it does not already exist), and versions of the native library for each supported runtime identifer (RID) (e.g., win-x64) will be placed in the appropriate subdirectories. When the .NET Core application is distributed, the entire runtimes directory should be deployed alongside it.
- For other types of projects (.NET Framework, UWP), only the native library version specific to the currently selected platform target (e.g., x64) will be copied to the output directory.
- For .NET Framework projects specifically, please note that the project's platform target (Project > Properties > Build Tab > Platform target) must be set to a real architecture. If it is set to "Any CPU", no native library will be copied to the output directory.
Windows:
The native library may alternatively be installed to the Windows system directory. This approach allows deploying both the 32-bit and 64-bit versions of the native library simultaneously, because each gets placed into the system directory that corresponds to the appropriate processor architecture.
Constants
File Attributes
Note: This attribute is not used by CBFS Sync, but it can be set and retrieved.
Note: This attribute is not used by CBFS Sync, but it can be set and retrieved.
Note: This attribute is not used by CBFS Sync, but it can be set and retrieved.