HashType Mismatch with --slow-hash-sync-only in OneDrive-Local Bisync

[nielash (Niel)]

To clarify one thing up front:

• local supports all hash types, but supports them slowly. (i.e. they are not cached – rclone needs to recalculate them when they are needed.)
• onedrive supports only QuickXorHash, which is not considered a “slow” hash type.
• Therefore, when bisyncing between local and onedrive, there is a “slow” hash on one side, but not the other.

@jahvlen

What do HashType1 and HashType2 represent?

They represent the hashtype used for bisync on path1 and path2, respectively. 512 is the code for QuickXorHashand 0 is none. We should probably display these in a more human-readable way in the logs.

@jahvlen

With --slow-hash-sync-only, I expected HashType1 (OneDrive) to use a slow hash (e.g., 512) and HashType2 (local) to skip slow hashes (e.g., 0). Why is the opposite happening (HashType1: 0, HashType2: 512)?

Since local and onedrive have only one hashtype in common (QuickXorHash), normally that is the one that would be used. That is why in your second example, they both show 512.

However, with --slow-hash-sync-only, you have instructed bisync to not generate hashes on the local side, where it can only do so slowly. That is why in your first example, one side is set to 0.

That said, I agree with you that it appears to be the wrong side. I would have expected it to be HashType2, not HashType1. I think there is a bug here:

cmd/bisync/compare.go

and I’ve never noticed it until now because I run bisync with the slow side on path1!

Thank you for pointing this out. Would you like to have the honors of submitting the one-line fix?