Frequently Asked Questions

Callback Technologies components are used to build virtual drives that expose any data source as a standard filesystem, antivirus and DLP agents that intercept file operations in real time, applications with transparent on-the-fly encryption scoped to specific processes, cloud sync clients with native OS status icons, custom Windows File Explorer extensions, encrypted file containers for DRM or records management, virtual block-level disk drives, and network monitoring or packet filtering tools. All without writing kernel driver code.

No kernel development is required. Each component ships with a pre-built, signed kernel driver that handles all low-level OS communication. Developers work with an event-driven API in user-mode code, implementing callback handlers that fire when filesystem, registry, or network events occur. This keeps application code in familiar, debuggable user space, eliminates the risk of kernel bugs crashing the system, and significantly shortens development time.

CBFS Connect includes a FUSE-compatible API, so existing FUSE knowledge transfers directly, with commercial support and stability hardening added on top. Compared to Dokan, CBFS Connect adds enterprise-grade reliability, active maintenance, and thorough documentation. CBFS Filter is built for scenarios where FileSystemWatcher falls short: high-load reliability, the ability to block or modify operations in flight, and registry and process monitoring alongside filesystem events. PCAP Filter uses the same BPF filter syntax as libpcap and Wireshark, and adds real-time packet modification, drop capabilities, and a consistent API across Windows, Linux, and macOS.

All Callback Technologies products support .NET with Visual Studio integration included, C++, Java, Python, Rust, Go, and Delphi. Most products also support Qt. All products include Visual Studio integration and sample applications in every supported language.

Platform support varies by product. CBFS Connect, CBFS Sync, CBFS Vault, and PCAP Filter support Windows, Linux, and macOS. CBFS Filter and CBFS Encrypt are Windows-only, as they rely on a Windows minifilter driver architecture. CBFS Vault additionally supports Android and iOS. CBFS Shell and CBFS Disk are Windows-only products.

CBFS Connect is a cross-platform SDK for creating and managing virtual filesystems. It allows developers to present any data source as a fully functional drive with folders and files, visible to the OS and all applications via standard file APIs. The virtual filesystem behaves identically to a real drive: applications can open, read, write, lock, and browse files without any awareness that the underlying data is being served by custom application code.

CBFS Connect acts as an intermediary between the OS filesystem layer and user-mode code. Instead of executing logic directly in the kernel, it proxies filesystem operations into callback events that your application handles via a user-mode component API. As a result, your code is isolated from the kernel entirely.

CBFS Connect handles this directly. The SDK ships with a pre-built, signed kernel driver. Developers implement event handlers in user-mode code — in .NET, C++, Java, Python, Rust, Go, Delphi, or Qt — that respond to filesystem operations such as file opens, reads, writes, directory listings, and deletions. CBFS Connect routes OS filesystem requests to those handlers and returns the results back to the calling application.

The result is a drive that appears fully real to Windows, Linux, or macOS, with no kernel coding involved. Sample projects are included for all supported languages to get from zero to a working virtual drive in minutes.

Any data source the application can access. Common examples include:

• Local or remote files and directories
• Database records presented as files and folders
• REST APIs and web services
• Cloud storage (S3, Azure Blob, Google Drive, or any custom backend)
• Dynamically generated or in-memory content
• Encrypted or compressed data that CBFS Connect transparently decrypts or decompresses on read

The application has complete control over what the virtual filesystem contains and how it responds to each operation. CBFS Connect imposes no constraints on the backend.

CBFS Connect supports a comprehensive set of filesystem features comparable to NTFS, including named streams, hard links, reparse points, directory change notifications, file locking, random read/write access and block-level access, fsctl requests, quotas, file IDs, short file names, and custom disk icons. It supports per-file and per-handle context objects, in-memory and disk caching options, and full NTFS security (ACL) mechanisms.

Mounting options include network mounting points, session-local mounting points, UNC paths, fixed and removable disk modes, and multiple mounting points per disk. Docker container support is included: the driver installs on the host and does not need to be part of container initialization.

The NFS component, introduced in CBFS Connect 2024, implements a local cross-platform NFS 4.1 server. It allows files to be mounted and served locally without requiring a kernel-mode driver at all, making it compatible with any NFS 4.1 client across Windows, Linux, and macOS.

It is particularly useful on macOS, where installing kernel extensions is restricted by Apple policy. If your use case requires driver-free operation or broad NFS client compatibility, the NFS component is the right choice. For scenarios requiring the full feature set of a virtual filesystem with NTFS-level capabilities, the standard CBFS component remains the better fit.

CBFS Connect supports creating virtual drives within Docker containers. The kernel driver is installed on the host machine only and does not need to be bundled inside the container or executed during container initialization. This keeps container images clean and avoids elevated privilege requirements at container startup.

CBFS Filter is a Windows SDK that allows applications to intercept, monitor, and control filesystem, Windows Registry, and process and thread operations in real time — without writing a minifilter driver from scratch. It ships a pre-built minifilter driver and exposes filesystem, registry, and process events to user-mode application code via a callback-based API.

CBFS Filter is used to build antivirus and endpoint security agents, data loss prevention tools, access control enforcement layers, continuous data protection systems, audit logging infrastructure, and on-the-fly file encryption. The latest release added file isolation and virtual file support.

CBFS Filter handles the driver layer entirely. Developers implement callback handlers in user-mode code — in .NET, C++, Java, Python, Rust, Go, or Delphi — that fire on the filesystem operations they care about. Filter rules let you target specific paths, file types, or processes, so your handlers are only called for the events you actually need.

From within a handler, you can allow the operation to proceed, modify the data being read or written, redirect the request to a different file, or block the operation entirely. Deployment uses a single CAB file containing all required drivers and helper DLLs, eliminating the architecture detection and signing complexity involved in building a minifilter driver from scratch.

File isolation allows different processes to see different contents when reading the same file. A trusted process can be given access to decrypted data while all other processes see only the encrypted form of the same file on disk. The divergence is handled transparently by CBFS Filter at the driver level with no changes required to the applications involved.

File isolation is used to implement per-process encryption, DRM systems, security sandboxes, and scenarios where different users or applications require different views of the same underlying data.

FileSystemWatcher is a user-mode .NET class that observes filesystem changes by reading notifications from a filesystem journal. It can miss events under high load or rapid change conditions, cannot intercept operations before they complete, and cannot block or modify any operation.

CBFS Filter operates via a kernel-mode minifilter driver and captures every operation reliably regardless of system load. It fires before and after operations complete, allowing data to be modified in flight or requests to be blocked entirely. CBFS Filter also covers Windows Registry and process activity, well beyond what FileSystemWatcher provides. A sample project is included that emulates the FileSystemWatcher API on top of CBFS Filter for teams migrating from that approach.

Yes. CBFS Filter includes three components beyond the core filesystem filter. CBRegistry provides full control over registry key creation, modification, enumeration, deletion, and redirection. It can protect specific keys and their values, redirect requests to alternate keys, and create virtual registry keys that Windows and third-party applications treat as real.

CBProcess monitors process and thread creation, suspension, and termination at the OS level. Access rights can be restricted to prevent undesired process operations and guard against potentially unwanted programs. CBMonitor provides passive filesystem monitoring without the ability to modify operations, suitable for audit logging and change tracking use cases.

CBFS Filter is a broad filesystem, registry, and process monitoring and control SDK. It can be used to implement encryption, but it can also intercept and modify any filesystem operation, monitor the registry, track process activity, implement file isolation, create virtual files, and enforce arbitrary access rules.

CBFS Encrypt is a purpose-built, streamlined toolkit focused specifically on transparent file encryption with process-based access control. It offers a simpler API for that one use case and is the right choice when encryption policy enforcement is the entire requirement. CBFS Filter is the right choice when encryption is one part of a broader security or monitoring system.

CBFS Encrypt is a Windows SDK for enforcing transparent file encryption policies with process-based access control. It uses a minifilter driver to automatically encrypt files on disk and decrypt them on the fly for authorized processes, keeping the encryption layer invisible to trusted applications while ensuring that any other process reading the same file receives only the encrypted bytes.

CBFS Encrypt is designed for developers who need to protect data at rest without requiring end users or authorized applications to take any action. It supports flexible rules targeting specific directories or file types, and deployment uses a single CAB file requiring no custom driver development.

CBFS Encrypt handles the driver layer entirely. Developers define encryption rules — targeting specific directories, file extensions, or patterns — and specify which processes are trusted to access decrypted content. CBFS Encrypt's minifilter driver then intercepts all file read and write operations matching those rules, applying encryption on write and decryption on read for authorized processes automatically.

Application code implements the rules and access policies using the CBEncrypt component API in .NET, C++, Java, Python, Rust, Go, or Delphi. No kernel coding is involved, and a sample project is included to demonstrate a complete working implementation.

When a file covered by an encryption rule is written to disk, CBFS Encrypt's minifilter driver intercepts the write operation and encrypts the data before it reaches the storage medium. When an authorized process opens that file for reading, the driver intercepts the read and decrypts the data before passing it to the application. The authorized process sees plaintext with no awareness of the encryption layer.

When any process not on the trusted list opens the same file, it receives the raw encrypted bytes. The file on disk is always stored in encrypted form. No separate encryption step, key management UI, or user action is required.

Process-based access control in CBFS Encrypt defines which processes are permitted to receive decrypted file contents. Trusted processes are identified by criteria such as executable path or digital signature. When a trusted process opens an encrypted file, CBFS Encrypt decrypts it transparently. All other processes receive the encrypted form of the file.

This model enables per-application data isolation, DRM enforcement, and zero-trust data-at-rest scenarios where files must remain unreadable to any process outside a defined trusted set, even for users with administrative privileges on the system.

CBFS Encrypt uses a rules-based engine that allows encryption policies to target specific directories, file extensions, or filename patterns. Rules can be scoped broadly across an entire directory tree or narrowly to specific file types within a path. The engine is designed to handle use cases of any scale, from protecting a single application data folder to enforcing encryption across complex enterprise storage layouts.

CBFS Encrypt uses modern cryptographic algorithms designed for both security and performance, minimizing latency while accessing files.

CBFS Sync is a cross-platform SDK for building bidirectional file synchronization between local filesystems and cloud storage or other remote repositories. It uses the same OS-level sync infrastructure as Microsoft OneDrive and other native sync clients: Cloud Filter API on Windows, File Provider on macOS, and FUSE on Linux.

Applications built with CBFS Sync display native OS sync status icons and indicators, providing users with the same experience they expect from built-in sync tools. The backend storage connection is entirely under the developer's control — CBFS Sync handles the local sync layer and fires events when changes need to be propagated.

CBFS Sync provides this directly. Because it wraps the same platform APIs used by OneDrive and other first-party sync clients, applications built with it automatically display native OS sync status overlay icons — syncing, synced, error — without any additional UI work.

Developers implement event handlers that fire when local folder changes are detected, then write the logic to push those changes to whatever remote storage is in use. CBFS Sync manages the local sync state, the OS integration, and the event dispatch. The backend can be any storage service or protocol the application can reach.

CBFS Sync wraps three platform-native technologies under a unified API: Cloud Filter API (CfAPI) on Windows, File Provider on macOS, and FUSE on Linux. These are the same APIs used by Microsoft OneDrive and other first-class sync clients on each platform.

Using these APIs rather than polling or filesystem watchers means sync events are delivered reliably by the OS, sync status icons integrate natively into the shell, and the sync client behavior matches user expectations on each platform without requiring platform-specific code in the application layer.

CBFS Connect creates virtual drives where files do not physically exist on the local disk. The application serves file contents on demand in response to filesystem operations. Files appear real to the OS and to other applications, but there is no local copy unless the application explicitly writes one.

CBFS Sync is for scenarios where files genuinely need to exist locally and stay synchronized with a remote source. It manages the local-to-remote sync relationship using OS-native sync APIs, and provides the native status icons and user experience associated with sync clients. If the goal is a mounted drive backed by remote data with no local persistence, use CBFS Connect. If the goal is a sync client where local files are kept in sync with a remote store, use CBFS Sync.

CBFS Sync supports Windows (Intel and ARM), Linux, and macOS. Support for iOS and Android is in active development. Language support includes .NET, C++, Java, Python, Rust, Go, Delphi, Qt, and macOS native bindings, with Visual Studio integration and sample applications included for all supported languages.

CBFS Shell is a Windows SDK for extending and customizing Windows File Explorer with virtual folders, custom context menus, overlay icons, custom detail columns, thumbnails, toolbars, and more. It allows developers to integrate deeply into the Windows Shell without the instability risks of traditional in-process shell extensions.

CBFS Shell uses an out-of-process architecture: a lightweight proxy runs inside the File Explorer process and communicates with application code via a local RPC mechanism. Application logic runs in the developer's own process, keeping File Explorer stable even if unhandled exceptions occur in the shell extension code.

CBFS Shell provides dedicated components for each of these capabilities. ShellFolder creates virtual folders that display custom data as files and folders within File Explorer, with full support for drag and drop, copy, paste, cut, delete, and link operations. ShellMenu adds custom items to the right-click context menu for any file or folder. ShellOverlays adds custom badge icons that appear directly over files and folders in Explorer, updatable in real time to reflect application-defined state.

All three components are used through a standard callback-based API in .NET, Java, C++, Python, Rust, Go, Qt, or Delphi, with no in-process COM development required.

CBFS Shell supports the following File Explorer customizations:

• Virtual folders that present custom data from any source as a navigable tree of files and folders
• Custom context menu items on any file, folder, or virtual item
• Custom overlay icons displayed over files and folders, updateable dynamically in real time
• Custom detail columns in the file list view, supporting both text and icon content
• Thumbnails, tooltips, and property pages
• Toolbars and ribbons
• Full end-user action support: drag, drop, copy, paste, cut, delete, link, go to, grouping, filtering, and search
• Path change monitoring via the ShellNotify component

Traditional shell extensions run as in-process COM servers inside the File Explorer process. An unhandled exception in that code crashes Explorer for all open windows. CBFS Shell avoids this by running application code out-of-process: a small proxy component runs inside Explorer and communicates with the developer's application via a local RPC mechanism. Explorer and the proxy remain unaffected by any exceptions or errors in the application code.

This architecture is also what enables shell extensions to be written in managed .NET code, which is not practical with in-process COM-based extensions.

Yes, and this is one of CBFS Shell's key practical advantages. Because application logic runs out-of-process via RPC rather than as an in-process COM server inside Explorer, there is no restriction on the runtime used. Shell Namespace Extensions and context menu handlers can be written entirely in C# or other managed .NET languages targeting .NET 5 through .NET 10.

Traditional in-process shell extensions have significant constraints around .NET usage due to COM hosting limitations. CBFS Shell's architecture eliminates those constraints entirely.

CBFS Vault is a cross-platform SDK for creating and managing self-contained file storage containers — a filesystem within a file. A Vault stores multiple files, folders, metadata, and encryption state inside a single container that can be placed on any storage medium: a hard drive, flash storage, a database record, raw memory, or custom hardware.

Vaults support random read and write access to individual files, per-file and whole-vault encryption, compression, journaling for crash resilience, alternate data streams, custom metadata attributes, and multithreaded operations. They can be embedded within application binaries, shared as standalone data files, or mounted as removable drives.

CBFS Vault handles this directly. The CBVault component API allows developers to create a Vault, add files and directory structures to it, apply per-file or whole-vault encryption using built-in modern cryptographic algorithms, and read or write individual files within the container with random access — no need to extract the entire archive to access a single file.

Vault containers are a single file on disk, making them easy to store, move, back up, and embed in application packages. Language bindings are available for .NET, C++, Java, Python, Rust, Go, Delphi, Qt, Android, iOS, and macOS.

ZIP files require decompressing the archive to access or modify content and do not natively support random writes, versioning, journaling, encryption scoped to individual files, or process-level access control. CBFS Vault supports all of these. Individual files within a Vault can be read or written without touching other files in the container. The journaling system protects against corruption if a write is interrupted. Per-file encryption means different files within the same Vault can have different encryption keys or settings.

CBFS Vault also supports alternate data streams, application-defined custom metadata attributes, compound document formats, and multithreaded concurrent access — making it a full embedded filesystem rather than a compression archive.

CBFS Vault uses journaling to protect against data corruption. Every change to the Vault's contents — file writes, directory renames, metadata updates — is recorded in an internal log before the change is committed. If the operation is interrupted by a crash or power failure, CBFS Vault uses the journal to restore the filesystem to a consistent state on next access.

The latest release of CBFS Vault added new journaling options for finer control over this behavior, allowing developers to tune the balance between write performance and recovery granularity for their specific use case.

CBFS Vault supports both per-file encryption and whole-vault encryption. Per-file encryption allows individual files within the same container to be encrypted independently with different keys or algorithms. Whole-vault encryption applies a single encryption layer across the entire container.

Built-in modern cryptographic algorithms are included. The API also exposes well-defined extension points allowing developers to supply their own encryption implementation, which is useful for integrating with existing key management infrastructure or meeting specific compliance requirements.

CBFS Vault is a filesystem-within-a-file: it manages its own internal structure of files, folders, metadata, and encryption within a single container, entirely in user space. It operates independently of the OS filesystem and is accessed via the CBFS Vault API. It runs on Windows, Linux, macOS, Android, and iOS.

CBFS Disk creates virtual block-level disk drives that the OS sees as raw storage devices. A standard filesystem such as NTFS or FAT is formatted on top of the virtual disk by the OS. CBFS Disk requires a kernel driver on Windows and is Windows-only. The right choice depends on the use case: CBFS Vault is better for application-level file containers, embedded data formats, and cross-platform scenarios. CBFS Disk is better for whole-disk virtualization, scenarios requiring OS-level filesystem access, or when you need the OS to manage the filesystem on top of your custom storage.

Yes. The CBVaultDrive component allows a CBFS Vault file to be mounted as a removable virtual drive, giving users and other applications standard file system access to its contents via a drive letter. This makes Vaults suitable for end-user-facing scenarios where a transparent, drive-like interface is desirable alongside the programmatic access provided by the CBVault API.

Each Callback Technologies license is tied to a single developer seat. One license permits one developer to build any number of applications using the SDK and deploy those applications to an unlimited number of end-user machines royalty-free. Additional seats are required for additional developers writing code that directly integrates the SDK.

Licenses are perpetual for the purchased version. An optional maintenance subscription covers major version upgrades and extends the active support entitlement beyond the initial coverage period.

Yes. Every Callback Technologies product is available as a fully functional 30-day trial with no feature restrictions. The trial includes the complete SDK, all components, full documentation, and all sample applications in every supported language. No account is required to download a trial.

Basic Support — covering knowledge base access and support ticket submission — is included automatically for the duration of the trial period.

Yes. A single developer license covers all projects built by that licensed developer using that product. There is no per-application or per-project restriction. The only constraint is that only one developer may use the license seat to write SDK-integrated code — other team members contributing SDK-related code require their own licenses.

Yes. Volume discounts are available for teams purchasing multiple developer seats. OEM pricing is available for ISVs embedding Callback Technologies components in products distributed to their own customers, and typically includes custom royalty structures, extended support terms, and source code escrow options.

Contact the Callback Technologies sales team at sales@callback.com to discuss specific requirements and receive a tailored quote.

Callback Technologies licenses are perpetual for the version purchased — they do not stop working. What expires is access to major version upgrades and the active support entitlement. Applications already built and deployed continue to run without restriction.

To receive updates beyond the covered version and maintain active support coverage, the maintenance subscription can be renewed at any time through the Callback Technologies website.

Callback Technologies offers three support tiers:

• Basic Support — included automatically with trial downloads. Covers knowledge base access, support ticket submission, how-to questions, basic code snippets, and bug reports for the duration of the trial period.
• Standard Support — included automatically with every paid license. Extends coverage to technical questions, code fixes, and the previous major product version in addition to all Basic Support entitlements.
• Premium Support — available as a paid add-on at purchase or any time afterward. Provides priority response times, direct access to Callback Technologies engineers, and expanded scope including debugging, protocol issues, limited source code analysis, and sample application creation.

Standard Support is included with every paid Callback Technologies license at no additional cost. It covers:

• Full knowledge base and documentation access
• Unlimited support ticket submissions
• How-to and technical questions
• Basic example code snippets
• Bug reports and code fixes
• Coverage for the current and previous major version of the product

Standard Support tickets are handled by the Callback Technologies engineering team directly, not a tiered helpdesk, for the duration of the active license.

Premium Support provides priority access to Callback Technologies engineers with a guaranteed response within one business day. It includes everything in Standard Support plus:

• Unlimited priority tickets covering licensing, installation, debugging, protocol issues, programming issues, environmental issues, and general use
• Investigation of connectivity problems, certificate validation issues, and end-user-reported problems
• Limited source code analysis related to the SDK components
• Creation of basic sample applications subject to scope review
• Priority scheduling for bug reports and code fixes

Premium Support can be purchased at the time of license purchase or added to an existing license at any time.

Response times by tier:

• Basic Support — best effort, typically within one business day but may take up to 2-3 business days depending on support volume
• Standard Support — typically within one business day, prioritized for active licensees
• Premium Support — guaranteed response within one business day

Support operates Monday through Friday during business hours. Premium Support tickets are reviewed ahead of Standard and Basic tickets regardless of submission order. Callback Technologies can also be reached by phone at (800) 340-9313.

For requirements beyond the scope of Premium Support, Callback Technologies offers Custom Development services and accepts Feature Requests. Custom Development covers building specific features, custom integrations, or specialized implementations not addressed by the standard SDK. Feature requests are reviewed for inclusion in the product roadmap.

Both can be initiated through the online forms in the Support section of callback.com, or by contacting sales@callback.com directly.