--copy-links and --hard-links

Matt McCutchen matt at mattmccutchen.net
Wed May 13 01:07:19 GMT 2009


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



More information about the rsync mailing list