Internal hashtable error: illegal key supplied! (v3.4)

[TonyTTTT]

With v3.4, getting error: Internal hashtable error: illegal key supplied!
(no error with 3.3)
MacOS 15.2

[stephenkorsman]

Same here for Ubuntu 24.04.1 LTS (Noble) using rsync version 3.2.7-1ubuntu1.1. I forced a reversion back to 3.2.7-1ubuntu1 which made rsync functional again.

[Athanasius]

Likewise with Debian's 3.2.7-1+deb12u1 released yesterday.

This is blocking some of my backups system (syncing files from one host to another). The Debian bug for this ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093052 ) points to this being related to combining -r and -H, something that is natural to do when wanting an accurate mirror of files.

[futatuki]

I also got same error on FreeBSD 14.2, like

Internal hashtable error: illegal key supplied!
rsync error: errors with program diagnostics (code 13) at hashtable.c(88) [generator=3.4.0]

It seems this is related to -H option (see also #702) and it causes if the source is a directory node without '/' and the destination is a directory, e.g:

# mkdir -p /var/tmp/rsync-test
# rsync -aAXHv --delete /etc/pam.d /var/tmp/rsync-test
Internal hashtable error: illegal key supplied!
rsync error: errors with program diagnostics (code 13) at hashtable.c(88) [generator=3.4.0]
# rsync -aAXv --delete /etc/pam.d /var/tmp/rsync-test
sending incremental file list
pam.d/
pam.d/README
pam.d/atrun
pam.d/cron
pam.d/ftp
pam.d/ftpd
pam.d/imap
pam.d/login
pam.d/other
pam.d/passwd
pam.d/pop3
pam.d/sshd
pam.d/su
pam.d/system
pam.d/telnetd
pam.d/xdm

sent 9,164 bytes  received 305 bytes  18,938.00 bytes/sec
total size is 8,130  speedup is 0.86
# rm -r  /var/tmp/rsync-test
# mkdir -p /var/tmp/rsync-test/pam.d
rsync -aAXHv --delete /etc/pam.d/. /var/tmp/rsync-test/pam.d
sending incremental file list
./
README
atrun
cron
ftpd
imap
login
other
passwd
pop3
sshd
su
system
telnetd
xdm
ftp => ftpd

sent 8,754 bytes  received 305 bytes  18,118.00 bytes/sec
total size is 8,130  speedup is 0.90
#

[chenx97]

It looks like rsync -rH /src/folder /dst/ fails, but rsync -rH /src/folder/ /dst/folder/ doesn't.

[frukto]

It looks like rsync -rH /src/folder /dst/ fails, but rsync -rH /src/folder/ /dst/folder/ doesn't.

sync -rH /src/A /src/B /dst/ /dst/folder/ works for me as well. Looks like everything is fine when multiple sources are specified.

rsync -rH /src/folder /src/folder /dst/ seems like a quick&dirty workaround.

[kpinc]

It looks like rsync -rH /src/folder /dst/ fails, but rsync -rH /src/folder/ /dst/folder/ doesn't.

rsync -rH /src/folder /src/folder /dst/ seems like a quick&dirty workaround.

It is not a quick and dirty work-around, because a trailing / on the source means something different than when the trailing / is omitted. The former copies the source directory itself whereas the latter copies the source's content.

[mach-o]

It looks like rsync -rH /src/folder /dst/ fails, but rsync -rH /src/folder/ /dst/folder/ doesn't.

Sadly I don't believe that this approach can work for those of us generating incremental backups using rsync's --link-dest option, though I admittedly haven't tried