bogus hardlinks bug?

John Van Essen vanes002 at
Mon Dec 1 00:19:09 EST 2003

On Sat, 29 Nov 2003, g <gmott at> wrote:
> i did:
> $  rsync -vRHSPa rsync:// .
> into an empty local directory
> the result was 140 bogus hardlinks of the same file:
[ snip ]
> i repeated the command without the "H" and it was hunky dory.
> $ rpm -q rsync
> rsync-2.5.5-4

This happens with 2.5.6, too.

I added this print statement in recv_file_list():

                if (verbose > 2)
                        rprintf(FINFO, "dev:inode = %lld:%lld\n",
                          (long long int) flist->files[i]->dev,
                          (long long int) flist->files[i]->inode );

Without -H, the dev and inode are zero.  But with -H, they are all:

dev:inode = 0:100

so that explains the hardlinking.

How does rsync know whether or not the other side can send dev:inode
information?  In flist.c, it's controlled by #if's at compile-time:

        if (preserve_hard_links && S_ISREG(file->mode)) {
                if (remote_version < 26) {
                        /* 32-bit dev_t and ino_t */
                        write_int(f, (int) file->dev);
                        write_int(f, (int) file->inode);
                } else {
                        /* 64-bit dev_t and ino_t */
                        write_longint(f, file->dev);
                        write_longint(f, file->inode);

What happens if the sender, for whatever reason, has no hard link support
compiled in?  What will the receiver be reading?
        John Van Essen  Univ of MN Alumnus  <vanes002 at>

More information about the rsync mailing list