First things first, this message:
2025/03/04 13:43:36 DEBUG : There are potential conflicts to check.
means that the same file is new or changed on both sides, relative to the prior sync. Instead of automatically assuming this is a conflict, we attempt to compare the current file on both sides (using something similar to rclone check) to see if they are equal. This is because if they are equal (i.e. the same new version was independently copied to both sides), we can avoid creating a .conflict duplicate where it isn't actually necessary.
This works perfectly when both sides support hashes, but presents a bit of a problem for crypt, which does not support hashes. For example, if you run a normal rclone check on two remotes, where one of them is a crypt, you'll see you get a message like ERROR : No common hash found - not using a hash for checks. Since rclone check never considers modtime, it ends up essentially falling back to --size-only in this scenario. This is not ideal for our purposes, because it is possible for two files to have the same size but different content. (Technically this is also true for hashes like md5, but much less probable -- making hash a much better choice than size for equality checking.) Therefore, we don't want to assume that two files are equal just because they have the same size.
Rclone has cryptcheck for this purpose (robustly comparing crypt to non-crypt), and so bisync attempts to use it in this situation. This is what the following message means:
2025/03/04 13:43:36 INFO : Encrypted drive 'idrive-sync-crypt:/': Crypt detected! Using cryptcheck instead of check. (Use --size-only or --ignore-checksum to disable)
However, an inherent side-effect of cryptcheck is that it has to basically read (i.e. download) the entire file on the non-crypt side and encrypt/hash it in memory on the fly. This can be quite slow, especially for large files. This is very likely why your sync slows to a crawl and doesn't complete for hours. This is also why you didn't experience this when using hasher -- because hasher can just use normal check with its stored hashes (which are very quick to retrieve).
Essentially, when bisyncing with crypt, users have to choose a tradeoff between:
- Default (detecting false conflicts is highly accurate, but can be slow)
- Use
--size-only or --ignore-checksum (less accurate, but much faster)
- Wrap your
crypt in hasher (accurate and fast, but less convenient as it requires the hasher overlay)
Personally I go with the hasher option for my needs. But I can also imagine use cases where the default would make sense (ex. bisyncing a repo of text files where size is small but accuracy is paramount.)
