bogus hardlinks bug?

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


On Sat, 29 Nov 2003, g <gmott at ntlworld.com> wrote:
>
> i did:
> $  rsync -vRHSPa rsync://rsync.mirror.ac.uk/updates.redhat.com/7.3/en/os/SRPMS .
> 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 SUPPORT_HARD_LINKS
        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);
                }
        }
#endif

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 umn.edu>




More information about the rsync mailing list