Repository and local directory structure

Syncany stores metadata locally in the .syncany directory of an initialized local directory, and remotely in the Syncany repository format. This small article describes both directory structures and the files within them.

Local directory

Once a local directory is initialized via sy init or sy connect, the Syncany folder contains a folder .syncany. This folder keeps the following data:

• /syncany (repo file, see RepoRemoteFile)
  The repo file (also: syncany file) stores common repository information needed by all clients. This includes the repository identifier (repo ID, randomly generated), chunking/multichunking options as well as compression options. If the repository is encrypted, this file is also encrypted.

• /master (master salt file, see MasterRemoteFile, optional)
  The master files stores the salt of the master key. It only exists if the repository is encrypted. Since the salt is a public value, this file is never encrypted.

• /config.xml (main config file)
  Stores the local machine and display name, the connection details to the remote storage / plugin as well as the master key.

• /cache/<cache files> (local cache)
  Temporarily stores files before upload or after download. With every start of Syncany, this directory is wiped.

• /db/<database files> (local SQL database)
  Files stored by the local embedded SQL database (currently HSQLDB). The local database stores the same metadata as are remotely stored in the db-<client>-<logicalclock> files, but in SQL tables.

• /logs/<log files> (log files)
  Stores log files created by Syncany. One log file per day. Currently no log rotation is implemented.

Remote repository format

Storage / connection plugins must be able to store different types of files. Where and how plugins store these files is up to the implementation of a plugin. That means that if it is more efficient, a plugin may very well store all files in a single blob, or in a million little files/entries/etc.

However, to keep a common structure for all plugins, it is suggested that plugins implement the following directory structure:

• /syncany (repo file, see RepoRemoteFile)
  Same as in .syncany/syncany. See above.

• /master (master salt file, see MasterRemoteFile, optional)
  Same as in .syncany/master. See above.

• /databases/db-<client>-<logicaltime> (database files, metadata, see DatabaseRemoteFile)
  For each sy up, a new database version is created and stored in a database file. Database files may contain 1-to-n databases of a single client/user/machine. The subdirectory databases is recommended, because clients frequently perform a list() on this directory.

• /multichunks/multichunk-<multichunk-id> (multichunk files, file data, see MultiChunkRemoteFile)
  Whenever new files are indexed and new chunks are created, these chunks are grouped into multichunks and uploaded to the repo. Multichunks contain the actual file data. The subdirectory multichunks is not needed for any technical reasons, but rather for logically grouping multichunks.