ActiveSync File Protection During USB Disconnects

Microsoft ActiveSync safeguarded Windows Mobile 6.5 devices against data corruption during sudden USB disconnections through a combination of atomic database transactions, temporary staging files, and a strict acknowledgment-based synchronization protocol. By ensuring that incoming data was fully transferred and verified before committing it to the device's permanent storage, ActiveSync prevented half-written records and broken file transfers from compromising system integrity.

Staged Writes and Atomic File Transfers

When transferring standard files over a USB connection, ActiveSync did not stream bytes directly into the target file on the Windows Mobile device's flash storage. Instead, the Remote Application Programming Interface (RAPI/RAPI2) created a hidden temporary file in the destination directory or temporary cache.

The data payload was written to this temporary file as packets arrived. Only after the entire payload was transferred, verified via packet checksums, and closed by the host did ActiveSync execute an atomic rename operation to replace or create the final target file. If a user unplugged the USB cable mid-transfer, the operating system simply left an incomplete temporary file behind—which was cleared during cleanup routines—leaving the original destination file entirely intact.

EDB Database Transactions and ACID Compliance

Windows Mobile 6.5 relied on the Embedded Database (EDB) engine, an evolution of the older CEDB, to store critical personal information manager (PIM) data like contacts, calendar appointments, and tasks. EDB supported full ACID (Atomicity, Consistency, Isolation, and Durability) properties.

During an ActiveSync session, database modifications were executed inside explicit transactions:

  1. Transaction Opening: ActiveSync initialized an EDB transaction before applying synchronization changes.
  2. Write-Ahead Logging: Changes were recorded in transaction logs rather than directly modifying the live database tables.
  3. Rollback on Disconnect: If the USB connection was interrupted before an explicit commit command was issued, the EDB engine detected the severed communication channel, aborted the operation, and rolled the database back to its exact pre-sync state.

Two-Way Handshakes and Synchronization Anchors

ActiveSync managed data alignment between the host computer and the mobile device using synchronization anchors (often referred to as watermarks or mapping tables). Every item synchronized had an associated tracking state.

The protocol enforced a strict alternating request-response cycle:

  • The host sent a batch of items.
  • The mobile device wrote the batch to temporary memory.
  • The device committed the batch and sent an acknowledgment (ACK) back to the host.
  • Only after receiving the ACK did the host advance its synchronization anchor.

If the cable was pulled at any point during this exchange, the handshake failed. Neither side updated its anchor to reflect a successful sync. Upon reconnection, both the host and the Windows Mobile 6.5 device compared their last validated anchor states, identified the unsynchronized delta, and seamlessly resumed the synchronization process without duplicating or corrupting records.

Network Layer Virtualization over USB

ActiveSync operated over USB by virtualizing a network adapter (NDIS over USB or serial-over-USB using Point-to-Point Protocol). Because the communication operated similarly to standard TCP/IP networking, abrupt physical disconnects were treated as dropped network sockets rather than low-level bus read/write failures.

This network abstraction shielded the underlying Windows Embedded CE 6.0 kernel from hard I/O crashes. The operating system's file system drivers (typically TFAT—Transactional File Allocation Table) received graceful closure signals when the connection layer timed out, keeping flash memory blocks and file allocation tables coherent.