Problems with rsync 2.5.1pre1 and hardlinks

[tim.conway at philips.com]

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

Tim Conway
tim.conway at philips.com
303.682.4917
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, 
19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970), 
".\n" '
"There are some who call me.... Tim?"




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

 
        To:     Tim Conway/LMT/SC/PHILIPS at AMEC
        cc:     birger at takatukaland.de
Dave Dykstra <dwd at bell-labs.com>
rsync at samba.org
        Subject:        Re: Problems with rsync 2.5.1pre1 and hardlinks
        Classification: 



On 12 Dec 2001, tim.conway at philips.com 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
Unix.