[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: http://sourceforge.net/mailarchive/forum.php?thread_name=bd11588a0812120517s15ae67b1lb742be0f63629614%40mail.gmail.com&forum_name=rsnapshot-discuss 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: https://bugzilla.samba.org/show_bug.cgi?id=5644 https://bugzilla.samba.org/show_bug.cgi?id=5645 https://bugzilla.samba.org/show_bug.cgi?id=5646 I would consider it worth forking rsync to have these features, if I ever got around to doing so. -- Matt -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html