On 29/10/21 11:07, Alessandro Baggi wrote:> Hi,
>
> I'm using rsync in a script to perform backups (using hardlink). It
> works very well. In my case I use an alternative output format to
> retrieve md5hash for every synced file so that I can save the hash and
> run an integrity check when needed. I use this because I noticed that
> the md5sum printed from rsync is like file md5sum and this avoid me to
> calculate md5 checksum for every downloaded file and I can save time
> (specially in the first backup on large dataset). Currently I use this
> command:
>
> rsyc -avElHA --out-format"%i||%n||%C" source dest
>
> (well, I have reduced the original command to this to see if the
> problem was generated by an option. The original command include ssh
> option and timeout and other option)
>
> The problem:
>
> I noticed that using rsync 3.2.3 (protocol version 31) the md5 hash
> does not correspond to the md5 file hash so if I run a check I got
> corrupted file alerts.
>
> My current backup machine runs Debian 11.1 with rsync 3.2.3 (installed
> from debian repository) and it works in pull. The following rsync
> version is related to remote host.
>
> What I tested (I tested only trasferring one file of ~30MB with the
> previous command):
>
> Sync from Debian 11.1 | problem found | rsync 3.2.3
> Sync from RockyLinux 8.4 | problem not found | rsync 3.1.3
> Sync from Debian 10.11 | problem not found | rsync 3.1.3
> Sync from Slackware15 (current) | problem found | rsync 3.2.3
> Sync file locally | problem found | rsync 3.2.3
>
> So this happens only when the remote host has rsync 3.2.3 while with
> rsync 3.1.3 no problem.
>
> I don't know if this is a bug or a new behaviour of the protocol.
>
> Any help will be appreciated.
>
> Thank you in advance.
>
> Alessandro.
>
Hi,
This is not a BUG. I read the manual page and found --checksum-choice
option. Setting this to md5 will solve the problem.
Thank you for your time.