rsync --link-dest option with the destination directory containing old files.

Matt McCutchen matt at
Tue Dec 23 18:52:21 GMT 2008

[Cross-posting this thread from rsync to rsnapshot-discuss because it
bears directly on rsnapshot's mode of operation.]

On Tue, 2008-12-23 at 10:00 -0600, Dave Dykstra wrote:
> Rob gave the example of
>     rsync -a --link-dest=../backup.1 source/ backup.0/
> where backup.0 already had files in it.  Is it that you're trying
> to alternate between backup.0 and backup.1 so you have two complete
> backups with as much hardlinked between them as you can?

Yes, I believe that is the use case.  More generally, consider
rsnapshot, which keeps a set of complete backups with as much
hard-linked from each to the next as possible.  Rsnapshot's current
approach to make a new backup is to "rm -r" the oldest, rotate, and then
copy the source to a new directory with --link-dest to the previous
backup.  An alternative approach is to let the oldest backup rotate to
the newest and then copy over it from the source, as Robert is
proposing.  The same thing has been proposed multiple times on the
rsnapshot list; see this thread and the older thread linked from it:

On Tue, 2008-12-23 at 23:45 +1100, David Overton wrote:
> I would also very much like to see this feature. Indeed, this seems
> far more logical than the current --link-dest behaviour and it's what
> I assumed --link-dest would do until I read the man page thoroughly
> (you have to follow the references back from --link-dest to
> --copy-dest and then --compare-dest and even then the only mention of
> the actual behaviour is a parenthesised comment "(if the files are
> missing in the destination directory)"). I be interested to know what
> use cases the current behaviour was designed for, because I can't
> see any advantage to not making use of the --link-dest file if it's
> available. Providing the proposed alternative behaviour as an extra
> option, if not the default for --link-dest, would be very useful.

I too find the current semantics of basis dirs illogical and would
support an option for better semantics (though I think we should avoid
changing defaults some users may be relying on).  That's why I entered a
series of enhancement requests, the first of which is Robert's proposal:

I would consider it worth forking rsync to have these features, if I
ever got around to doing so.


More information about the rsync mailing list