This topic covers the process of specifying the database directory on the command line by using -b (local) and -B (remote). Snap DB does not work on CIFS, NFS, or other shared file systems mounted on Linux, thus -B/-b must specify a directory on a file system physically local to the endpoint host. The first concept to grasp in this topic is that async creates a private directory (~private-asp) for the following purposes: Since the database directory can be specified on the command line using -b (local) and -B (remote), there will be a ~private-asp directory in the sync directory (used for transfer cache) and a ~private-asp directory in the -b/-B directory that stores the DB. Note that because multiple sessions can sync the same directory or specify the same DB directory (-b/-B), async creates a subdirectory under ~private-asp for each session (with the name specified using -N). The session name only allows standard alphanumeric, plus the "_" and "-", characters, so that it can be created as a directory. This subdirectory is created on both sides if needed by the direction of the transfer and DB location (see below for details).

Each async session must have a UNIQUE name (as specified with -N). If multiple sessions sync the same directory or specify the same DB directory (-b/-B), then the session names MUST be unique. The snapshot DB records the session name and the sync directories (local and remote). If you initiate a second async session with the same name, using the same sync directory on one end but a different directory on the other end (or both directories are different, but the DB location is the same), async will fail.

IMPORTANT NOTE: You can synchronize between a Windows endpoint and a Windows server, as well as between a Windows endpoint and a Linux server. In async, the path separator "/" works equally well on Windows and other platforms. The path separator "\" works only on Windows. The examples below use "/" uniformly.

Example 1: Bi-directional async  

> -N ex1 -b c:/db -B d:/aspera/var -d c:/data/users -r admin@server:d:/storage/users -K bidi 

Creates the following on the local computer (initiator):

Creates the following on the remote computer (reactor):

Example 2: Uni-directional async

> -N ex2 -b c:/db -B d:/aspera/var -d c:/data/users -r admin@server:d:/storage/users -K push

Creates the following on the local computer (initiator):

c:/db/~private-asp/ex2/snap.db

Creates the following on the remote computer (reactor):

Changing Direction Between Runs

Changing direction between runs is not allowed. async will fail with an error message and you must run with --reset or provide a new DB directory.

Starting up when a Snapshot DB is Missing

async cannot start when only one of the snapshot databases is present; thus, you must either clean it or start async with --reset. The DB is located under the regular private directory by default, although its location can also be specified by start-up parameters. Behavior with respect to presence of the private directory and db file are as follows:

On the client:

  1. If private directory doesn't exist, create it.
  2. If DB directory doesn't exist (meaning the DB doesn’t exist), create it and the DB, and remember "there was no DB."
  3. If DB file doesn't exist, create it and remember "there was no DB."
  4. Tell remote whether the DB existed.

On remote:

  1. Same as client 1, 2 and 3.
  2. Determine if "there was no DB."

If there is a discrepancy (local DB existed, but no remote; or, remote existed but no local), tell the client there is an error. If a subsequent run specifies different DB directories, the above behavior is preserved. In other words, even if a DB exists in the regular private directory or elsewhere, it considers "there was no DB" if there isn’t a database in the specified directory.

Deleting the Snapshot DB during Synchronization Results in Undefined Behavior

To recover, stop async, delete the DB on the other side as well, and restart.