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