This bug leaks a chunk every time files in a revision are listed. Not a big
deal for backup and restore, but it becomes problematic when listing files in
many revisions for commands such check and history.
The version bit should not be set to 1 when encoding a snapshot. Instead,
it must be set to 1 on snapshot creation.
To correctly process old snapshots encoded incorrectly with version bit set
to 1, the first byte of the encoded file list is also checked. If the first
byte is `[`, then it must be an old snapshot, since the file list in the new
snapshot format always starts with a string encoded in msgpack, the first
byte of which can't be `[`.
Main changes:
* Change the listing order of files/directories so that the local and remote
snapshots can be compared on-the-fly.
* Introduce a new struct called EntryList that maintains a list of
files/directories, which are kept in memory when the number is lower, and
serialized into a file when there are too many.
* EntryList can also be turned into an on-disk incomplete snapshot quickly,
to support fast-resume on next run.
* ChunkOperator can now download and upload chunks, thus replacing original
ChunkDownloader and ChunkUploader. The new ChunkDownloader is only used
to prefetch chunks during the restore operation.
You can now add a key 'filters' in the preferences file that points to the
path of the filters file. If this key is not found in the preferences,
the default location '.duplicacy/filters' is used.
There is a new option '-filters' for the set command that set this key in
the preferences, but you can also edit the file directly.
Do not "misuse" property nobackupFile to trigger this feature.
- Restructured ProcessFilterFile function and splitted it in smaller parts.
- Prepare usage of new filter syntax for arguments of restore command.
- Using @<filename>, you can now include other files. Relative paths are supported.
This is useful, if you have several repositories with some different filters and a common filter base set.
Directories containing a file with this name will not be backed up. I find it easier to drop a .nobackup file in directories I don't want backed up instead of maintaining a file of exclusions. This is also useful for scripts that create data in the repository but don't want it to be backed up.
