On Fri, Dec 10, 2010 at 02:42:45PM -0800, Steven Levine wrote: > In <20101210220340.gi27...@digitalkingdom.org>, on 12/10/10 at > 02:03 PM, Robin Lee Powell <rlpow...@digitalkingdom.org> 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. -Robin -- http://singinst.org/ : Our last, best hope for a fantastic future. Lojban (http://www.lojban.org/): 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: http://www.digitalkingdom.org/rlp/ -- 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