Please note that setting up selective sync in a way we describe in this post requires advanced computer management skills. We don’t recommend experimenting with these settings if you are not comfortable with managing apps via command lines. Wrongful setup could cause permanent data loss.
Advanced Selective Sync will let you create custom synchronization rules. For example, you can set a rule to exclude specific file types from sync, preventing them from being uploaded to the cloud.
How to set it up?
Advanced Sync options can be managed via the files you can find in the hidden .tresorit folder in each synced tresor. This means that changes you make using this method will not get displayed in the application interface.
Create the files that will control the selective synchronization process: under the hidden .tresorit folder in each synced tresor.
- Create the ‘Filters’ folder in the hidden .tresorit folder in the synced tresor you wish to customize.
- Create .tresorit/Filters/roaming.filter
Applies to every user of the tresor, this file is synchronized. It might contain default rules that should apply to every member of the tresor.
- Create .tresorit/Filters/local.filter
Your local filter file. Please note that by modifying this you can overwrite hardcoded (security) rules and default tresor behavior through attributes.
- Please note that by default these are not present: you will have to create the Filters folder and the above mentioned files. The file and folder names must match exactly with the above one. Please pay special attention to upper and lower case letters.
Create custom synchronization rules
Every line of a filter file is a rule, except empty lines and comments. A rule follows this format:
[<List Of Attributes>] <Relative Path>
Comments start with # or // (only at the beginning of the line!).
By defining custom attributes, you can influence the synchronization algorithm of the given relative path in the tresor. The available attributes are:
- Sync – (default) Synchronize the path
- Ignore – Ignore synchronization of the path
- Junk – Ignore synchronization of the path and it may be deleted if neccessary (if the parent directory is deleted from the cloud)
- Remote – (default) use remote timestamps on downloaded files
- Local – use local timestamps on downloaded files
- Normal – (default) use normal thread categories for syncing
- Priority – use a priority thread for syncing
- (default: 3) It is an unsigned integer to influence the priority of the synchronization tasks. Valid values: 1 - 5
The following attributes modify the scope of the rule (which directories and files it applies to)
- File – to match the path for only files
- Directory – to match the path for only directories. If it matches a directory, it will apply to its children recursively as well.
- Unspecified – (default) to match anything. If it matches a directory, it will apply to its children recursively as well.
- False – (default) the path in the rule is considered to be case-insensitive
- True – the path in the rule is considered to be case-sensitive (use this carefully, it's effect can be unexpected when syncing on a case-insensitive file system)
Attribute values formatted with underlined and bold fonts can be used without an attribute key.
[Sync=Junk, PathType=File] ...
# is equivalent to
[Junk, File] ...
Default path attributes
Putting together the rules above, the default attributes that apply to all files and folders could be written as:
[Sync, Date=Remote, Threading=Normal, Priority=3, PathType=Unspecified, CaseSensitive=False] Path
The filter files have a quite simple syntax for defining relative path patterns.
- The easiest way is to enlist the full paths to be modified. Please note that you can use only forward slashes in paths (back slashes are replaced with forward slashes).
- This rule will exclude this specific file from syncronization.
- [Ignore] Directory/file.txt
- To create more complex settings, you can utilize basic rule generation patterns. These rules will make sure that parent directories are handled correctly for recursive synchronization. For example, a selective sync like behavior could be written as
- These two will ignore all files and directories by default, and add a rule for "Foo" directory to be synced and all its children to be ignored, only the "Bar" directory to be synced which will result in syncing only the selected (Foo/Bar) directory.
- [Ignore] //*
- [Sync] Foo/Bar
- You can use (multiple) joker characters with basic rule generation. "//" will match for any subpath and "*" will match for a single path component (everything except "/") Using this method for example:
- Ignore all files.
- Sync all direct subdirectories of "Directory" and all "file.txt" files inside them.
- Sync all C directories inside directories that match the "A*B" pattern inside the "A" directory.
- This will ignore all Debug directories in the tresor at any depth. This is the rough equivalent of .gitignore
- Sync all .config files across the tresor.
- [Ignore] //*
- [Sync, File] Directory/*/file.txt
- [Sync] A/A*B/C
- [Ignore] //Debug
- [Sync, File] //*.config
Rules are processed in order. Thus a rule which is after another one will have higher priority. Rule processing order:
- roaming.filter file is processed,
- Selective sync, mobile offlines are applied afterwards (IMPORTANT: this can overwrite previously set rules)
- then hardcoded rules are applied (mostly for ignoring most of the .tresorit directory and temporary files),
- after that local.filter rules are processed.
The hardcoded rules are roughly equivalent to this:
# Ignore synchronization's temp files, local.filter and Trash directory
# Sync the roaming.filter (and the .tresorit/Filters directory, which is necessary)
# Temp files which can be deleted if their containing folder gets deleted
# In the line below \r is a single character
[Junk] //* .tmp
# Other temp files which should not be deleted if their parent directory gets deleted
[Ignore] //System Volume Information
Basic information about the synchronization process
Synchronization tasks are created recursively starting from the root of your tresor and directories and files are processed separately. Attributes are checked on each synchronized file and directory path. At any depth we can check the path attributes only if the parents were synchronized as a result of the encryption, for example we do not know if there is an Foo/Bar/baz.txt file (therefore we cannot sync it) unless we sync both Foo and Foo/Bar directories – rule generation takes care of this problem in most use cases.
A file (or directory) is ignored if at least one of Ignore or Junk is set.
Still have questions left? Drop us a line