If one had an attacker trying to produce a collision, letting them change the data size would make it easier, however I’m not finding that anyone has ever found a SHA-256 collision. Its search space is:
>>> print(2 ** 256)
115792089237316195423570985008687907853269984665640564039457584007913129639936
(first time I’ve tested the Python 3 claim of unlimited integer precision – which is sometimes desired)
Opinions that I can find on your thought include the following. I don’t know who’s really expert or not:
Are hash collisions with different file sizes just as likely as same file size? seems to vary from “no” to perhaps reducing the above astronomically large number by 5 digits for a default 102400 block size.
When hashing, do longer messages have a higher chance of collisions? is in security context, where longer passwords are generally viewed as safer. A 1 character password is too easy to brute-force…
Why haven’t any SHA-256 collisions been found yet? is from a crypto group, and probably makes it irrelevant whether hash collisions are higher or lower given varying block size. It’s low risk either way.
EDIT 1:
Although I think we’re more in a random-chance than an attack situation attempting to find a collision,
Rainbow table is how one finds weak short passwords really easily, and why salted hash is preferred. Beyond that, people go out of their way to use many rounds of slow algorithms to deter the guessing:
How many rounds of hashing is enough for a password manager?
EDIT 2:
Why doesn’t Bitwarden officially recommend Argon2? is another example of algorithm versus rounds.
Fortunately, Duplicati just uses the SHA-256 (maybe augmented by Size) as its way to identify things.
The exception to that is the GUI login password, but that’s quite far out of scope for a dindex blocklist.