Problems with rsync 2.5.1pre1 and hardlinks

tim.conway at tim.conway at
Thu Dec 13 10:49:30 EST 2001

Well, I'll be damned.  I'd never run into that trick.  My apologies.

Tim Conway
tim.conway at
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, n9hmg on AIM
perl -e 'print pack(nnnnnnnnnnnn, 
".\n" '
"There are some who call me.... Tim?"

Martin Pool <mbp at>
12/12/2001 03:27 PM

        To:     Tim Conway/LMT/SC/PHILIPS at AMEC
        cc:     birger at
Dave Dykstra <dwd at>
rsync at
        Subject:        Re: Problems with rsync 2.5.1pre1 and hardlinks

On 12 Dec 2001, tim.conway at wrote:

> An additional hard link to an existing file takes only directory
> space, which, if it's not enough of an addition to that directories
> existing data to cause the filesystem driver to add another
> allocation to the directories data space, takes up no more disk
> space.  A symlink, however, has the same effect in the directory,
> but, in addition, gets its own data space, and inode, as well.

Actually on Linux (and some others?) the content of a symlink is
normally stored *inside* the inode, in the space that would otherwise
be used for pointers to the data and indirect blocks.  This only helps
if the target of the symlink as a string is short enough to fit in
this uint32[15] field, in other words 60 bytes.  These are called
"fast symlinks", and you can see them listed separately in the output
of e2fsck.  Of course as well as not occupying blocks they have the
advantage of being read faster, and not using any time in modifying
block allocation maps, etc.

If the symlink is longer, data blocks are allocated as on classic

More information about the rsync mailing list