Exclude specific file types from sync (advanced)

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.

📚 You might be interested: Using selective sync

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

Filter syntax

Every line of a filter file is a rule, except empty lines and comments. A rule follows this format:

Comments start with # or // (only at the beginning of the line).

Attributes

By defining custom attributes, you can influence the synchronization algorithm of the given relative path in the tresor.

The available attributes are:

Sync

• 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)

Date

• Remote — (default) use remote timestamps on downloaded files
• Local — use local timestamps on downloaded files

Threading

• Normal — (default) use normal thread categories for syncing
• Priority — use a priority thread for syncing

Priority

• (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)

PathType

• 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.

CaseSensitive

• 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.

Example

Default path attributes

Putting together the rules above, the default attributes that apply to all files and folders could be written as:

Path Examples

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.

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.

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:

1. Ignore all files.
   [Ignore] //*
2. Sync all direct subdirectories of "Directory" and all "file.txt" files inside them.
   [Sync] Directory/*/file.txt
3. Sync all C directories inside directories that match the "A*B" pattern inside the "A" directory.
   [Sync] A/A*B/C
4. This will ignore all Debug directories in the tresor at any depth. This is the rough equivalent of .gitignore
   [Ignore] //Debug
5. Sync all .config files across the tresor.
   [Sync] //*.config

Rule processing

Rules are processed in order. Thus a rule which is after another one will have higher priority. Rule processing order:

1. roaming.filter file is processed,
2. Selective sync, mobile offlines are applied afterwards (IMPORTANT: this can overwrite previously set rules)
3. then hardcoded rules are applied (mostly for ignoring most of the .tresorit directory and temporary files),
4. after that local.filter rules are processed.

Hardcoded rules

The hardcoded rules are roughly equivalent to this:

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