rsync - May 2009 - --copy-links and --hard-links

Hi,

I want to use rsync in a may be unusual way:

I have a source tree containing lots of symbolic links and I use
the option "--copy-links" to get the physical files (the referents of
the symlinks)
on the target host.

As the host uses the synchronized files in a read-only fashion, I also want to
get
hardlinks for all identical files, to save space. Thus I also use
"--hard-links".

Because managing hardlinks is hard to handle (some lookup table is needed),
only inodes with a hardlink count >1 are considered (flink.c:1250
"st.st_nlink > 1").
Unfortunately most of my symlinked files have a link count of 1 and thus they
are copied
twice. If, however, the source file accidentally has a link count > 1 (which
is not related
to the multiple symlinks) rsync will create a hard link on the target host, as
supposed.

To handle this situation I simply disabled the (st.st_nlink > 1) filter if
"copy_links" is true, too.
This seems to work for me, but I don't know if this is a sufficient solution
for others.
May be a special option should be considered to disable the (st.st_nlink > 1)
optimization explicitly.

Or my situation is too exotic to be considered to fix.

Dieter.

-------------- next part --------------
HTML attachment scrubbed and removed

On Tue, 2009-05-12 at 17:18 +0200, Dieter St?ken wrote: 
> I want to use rsync in a may be unusual way:
>  
> I have a source tree containing lots of symbolic links and I use
> the option "--copy-links" to get the physical files (the
referents of
> the symlinks)
> on the target host.
>  
> As the host uses the synchronized files in a read-only fashion, I also
> want to get
> hardlinks for all identical files, to save space. Thus I also use
> "--hard-links".
>  
> Because managing hardlinks is hard to handle (some lookup table is
> needed),
> only inodes with a hardlink count >1 are considered (flink.c:1250
> "st.st_nlink > 1").
> Unfortunately most of my symlinked files have a link count of 1 and
> thus they are copied
> twice. If, however, the source file accidentally has a link count > 1
> (which is not related
> to the multiple symlinks) rsync will create a hard link on the target
> host, as supposed.
I see: many of your source files have only one hard link, but that hard
link appears in multiple places in the file list, and you want those
paths hard-linked together on the destination.  This can happen due to
--copy-*links options, source args that go through symlinks or even just
have differently-placed "/./" sequences with --relative, or bind
mounts.
Perhaps users who want to handle those cases correctly at some
performance cost could pass --hard-links --hard-links to disable the
(st.st_nlink > 1) check.

Currently, repetition of --hard-links is recognized by server_options in
options.c but doesn't actually have any effect on rsync's behavior.
Wayne, is there a reason for this?

-- 
Matt