Deployment
The user-mode libraries come as
- Windows: dynamic libraries with import libraries, named cbfssync26.dll and cbfssync26.lib, respectively (available for x64, ARM64, and x86 processor architectures)
- Linux: dynamic libraries, named libcbfssync.so.26.0 (available for x64 and x86 processor architectures)
- macOS: dynamic libraries, named libcbfssync26.0.dylib (available for x64 and ARM64 processor architectures)
Windows: Deploy the .dll file to the target system and place it next to the application's .exe file.
Alternatively, the native 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
Linux:
To link the CBSync class to your application and use them properly, the FUSE 2.9 package must be installed in your development system. This can be achieved using the following commands:
- RedHat/CentOS and derivative Linux distributions: sudo yum install fuse-devel
- Debian/Ubuntu and derivative Linux distributions: sudo apt-get install libfuse-dev
- Debian/Ubuntu and derivative Linux distributions:
- End-user library: sudo apt update && sudo apt install libfuse3-3
- Development headers: sudo apt install libfuse3-dev
- Fedora / RHEL / CentOS Stream / Rocky Linux / AlmaLinux:
- End-user library: sudo dnf install fuse3 fuse3-libs
- Development headers: sudo dnf install fuse3-devel
- Arch Linux: sudo pacman -S fuse3
- openSUSE (Leap / Tumbleweed):
- End-user library: sudo zypper install fuse3
- Development headers: sudo zypper install fuse3-devel
- Alpine Linux:
- End-user library: sudo apk add fuse3
- Development headers: sudo apk add fuse3-dev
Threading and Concurrency
The class utilizes different underlying technologies on different operating systems. Because of that, the threading model exposed to applications depends in part on the platform class runs on.
NOTE: Even when configured for minimal concurrency, the class always fires events in the context of some worker thread, and not in the thread the class was originally created on. Therefore, applications must be sure to synchronize operations between event handlers and other threads as necessary (including, but not limited to, calls to the class instance, unless a method is explicitly documented as callable within events).
Configuring Event Concurrency
The SerializeEvents property controls whether events relating to different files should be allowed to fire in parallel on several worker threads, or serialized on a single worker thread. By default, this property is set to seOnMultipleThreads, and events for different files are allowed to fire in parallel.
Windows: Generally speaking, the class always enforces per-file event serialization; that is, events relating to the same file are always fired in sequence regardless of the property value. With per-file event serialization already ensured, the most important concurrency-related consideration is whether to enforce multifile event serialization as well, which is what SerializeEvents controls. When SerializeEvents is set to seOnMultipleThreads, the MinWorkerThreadCount, MaxWorkerThreadCount, and WorkerInitialStackSize configuration settings let the application tune the worker thread pool. These settings are ignored when SerializeEvents is set to seOnOneWorkerThread.
Linux: When SerializeEvents is set to seOnMultipleThreads, the class may fire events related to the same file concurrently in several threads. If the application is not prepared for that, it should use seOnOneWorkerThread mode.
macOS: The events always fire on a single worker thread, and the SerializeEvents property has no effect.