rsync --link-dest, --delete and hard-link count

Paul Slootman paul+rsync at wurtel.net
Mon Feb 8 03:19:56 MST 2010


On Sat 06 Feb 2010, grarpamp wrote:
> >
> >> Sure, these no-longer-present source files are not technically unlinked from
> >> your previous archives in the current run, but it can be MASSIVELY confusing
> >> and dangerous if you're a log watcher/reviewer looking for what has changed.
> >
> >  Only if you don't understand what's going on.

> Since it's not a documented caveat of using link-dest, and the user never sees
> it in the -i output, I'm sure there are plenty of folks for which this
> realization
> would never occur until it's too late.

Personally, I've never had the expectation that it would report files
that aren't transferred but exist in the link-dest tree.

> It's simply that rsync _can_ be made to do all this in one invocation.
> Since it has to look at and consider all three of source, prior and current
> anyways, it makes sense to enhance it with this printing capability.

It only checks the link-dest trees for existence of the files to be
transferred. It doesn't build a list of all files in all the specified
link-dest trees (remember that you can pass any number of --link-dest
arguments). It would make rsync quite a bit slower if it's forced to
traverse those trees just for reporting whether a file doesn't exist
anymore in the new tree.

I suggest first creating a duplicate of the tree you now pass as
link-dest via cp -al, and then running rsync without the --link-dest but
with --delete, for your specific requirements.

> I don't have much use for userfriendly bloated scripts like dirvish/etc.
> Not to knock them, they're fine for those who use them. I just prefer
> putting only what I need into my own along with adding other bits.

Where's the bloat? It has a lot of sensible checks, and a perl script of
28k isn't that bad. At least it's a whole lot less overhead than forcing
rsync to build a list of the files in the link-dest tree (admittedly
dirvish builds the tree with find, but then only if asked).

Rsync would then need an extra option to enable it to report such
"deleted" files, because I sure don't need that nor do I need the extra
overhead that encurs. And how do suggest it reports from which trees the
file is "deleted"?


Paul


More information about the rsync mailing list