Skip to content

Remote File Hierarchy

Michael Fey edited this page May 10, 2013 · 4 revisions

The remote directory structure and hierarchy used by the TICoreDataSync framework

TICoreDataSync uses a pre-defined hierarchy of directories and files to store information at the “remote.”

The root directory for an application uses the global app identifier specified at app registration. If a user opens this directory wondering what it’s for, there’s a ReadMe.txt file inside to explain its use. This file is added by the framework the first time a client registers the application; if you wish to customize the contents, replace the ReadMe.txt file inside TICoreDataSync’s 05 File Structure directory.

Root Level

The root level (com.companyName.globalAppName) of the hierarchy contains the following:

File Description
ReadMe.txt Plain text file containing information for users browsing the directory.
ClientDevices/ Directory containing UUID subdirectories for each registered client, contents described in Client Devices.
Documents/ Directory containing UUID subdirectories for each registered document; contents described in Documents.
Encryption/ Directory containing files relating to encrypted data; contents described in Encryption.
Information/ Directory containing subdirectories related to certain important events, such as the deletion of a document or client device; contents described in Information.

Note that each of these directories always exists, even if empty — i.e., the Encryption directory is created even if encryption is disabled.

Client Devices

The ClientDevices directory contains subdirectories, named using the unique client identifiers, with one directory per registered client. Each client’s UUID subdirectory contains:

File Description
deviceInfo.plist Property list file containing information about the registered device, including a human-readable description.

If you supply user info at application registration, this will also be saved in the deviceInfo.plist the first time the device is saved, and passed back any time you access the list of clients registered with an application or specific document.

Documents

The Documents directory contains subdirectories, named using the unique document sync identifier, with one directory per registered document. Each document’s UUID subdirectory contains:

File Description
documentInfo.plist Property list file containing information about the document, including original file name, original device, etc.
DeletedClients/ Directory containing UUID files indicating the sync ids of clients whose information and directories have been removed from synchronizing with this document.
RecentSyncs/ Directory containing files, named using the unique client identifiers, with one file per client registered to synchronize with thie document. The modification date indicates the last time the client synchronized.
SyncChanges/ Directory containing UUID subdirectories for each client registered to synchronize with this document. Each subdirectory contains .syncchg files describing a set of Sync Changes.
SyncCommands/ Directory containing UUID subdirectories for each client registered to synchronize with this document. Each subdirectory contains .synccmd files describing a set of Sync Commands (Sync Command functionality is not yet implemented in TICoreDataSync).
TemporaryFiles/ Directory containing subdirectories (currently only a WholeStore subdirectory) used during certain operations to hold temporary files (such as when uploading store files).
WholeStore/ Directory containing the most recently-uploaded store files for each client; contents described in WholeStore.

If you supply user info at document registration, this will also be saved in the documentInfo.plist the first time the document is registered by any client, and passed back when requesting e.g., a list of registered documents.

Whole Store

The WholeStore directory contains subdirectories, named using the unique client identifiers, with one directory per registered client. Each client’s UUID subdirectory contains:

File Description
AppliedSyncChangeSets.ticdsync SQLite file containing the UUIDs of sync change sets that have already been applied to the WholeStore.ticdsync store file.
AppliedSyncCommandSets.ticdsync SQLite file containing the UUIDs of sync command sets that have already been applied to the WholeStore.ticdsync store file.
WholeStore.ticdsync A copy of the entire store file. Note that it doesn’t matter to the framework what type of store you use—it should work with SQLite, XML, binary, or custom stores.

Whenever you initiate a store upload or download, TICoreDataSync always sends the AppliedSync*Sets files too.

Encryption

The Encryption directory contains files used to encrypt and decrypt files during synchronization. These are:

File Description
salt.ticdsync File containing random data used as salt by the FZACryptor class during encryption and decryption.
test.ticdsync File created with partial known content at initial registration when encryption is enabled, and used by subsequent devices to test whether a provided password is correct.

For more information about what is encrypted, see the Framework Overview.

Information

The Information directory is used to alert clients at registration that something has happened, such as the deletion of a document or client device.

File Description
DeletedDocuments/ Directory containing UUID files indicating the sync ids of documents that have been deleted.DeletedClients/Directory containing UUID files indicating the sync ids of clients that have been deleted from the entire application.