Very surprising behaviour with --files-from

Robin Lee Powell rlpowell at
Fri Dec 10 17:08:17 MST 2010

On Fri, Dec 10, 2010 at 02:42:45PM -0800, Steven Levine wrote:
> In <20101210220340.GI27025 at>, on 12/10/10 at
> 02:03 PM, Robin Lee Powell <rlpowell at> said:
> Hi,
> >On the other hand, given this:
> >cpool/b/c/5/bc50007d8ab0221cb2b2b61e0754224c
> >cpool/b/c/5/bc500094bb43d0f4235363f65658d231
> >cpool/7/7/8/77865de94585b4581f07e54065c7b1e3
> >, that is, same files, changed order, we have:
> >In the middle case, it checks all the /b/ stuff a second time
> >because of *the order of the file*.
> I missed this.  My test case was right, but I did not supply
> sufficient -v's to see it and I did not have time to look at the
> code.  The list I saw was after sorting and the duplicates were
> gone.
> >Which is fine and appropriate in terms of RAM usage, I guess, but
> >very very surprising.
> I don't think the issue is RAM use per se.  Reviewing the code,
> I'd say it's more likely that no one considered the performance
> impact of huge, out of order file lists.  I would not consider
> your use case standard.

Oh, I completely agree that my use case is unusual.  The resulting
behaviour is still a shock, though.

> >I call this a feature, but a documentation fail.  At least, I
> >can't find anything in the docs that mentions "and you'd better
> >sort the file or you won't like the results at all".
> I recommend you put in an documentation enhancement ticket for
> this.

Doing that now.


-- :  Our last, best hope for a fantastic future.
Lojban ( The language in which "this parrot
is dead" is "ti poi spitaki cu morsi", but "this sentence is false"
is "na nei".   My personal page:

More information about the rsync mailing list