duplicated file removal: call for comment

[Thomas Osterried]

I fully agree with jw schultz's first and second issue, to his --delete
assumption and to the the point that lexical order does not matter.

> This unfortunately does mean that a means of preserving
> initial sequence must be incorporated or the qsort approach
> to finding duplicates would have to be forgotten.
> This could be as simple as running qsort on an array of
> indices to flist->files instead of flist->files itself.

qsort is a problem and it's clear why.
i just wonder, why in real-life it always woked fine for me ;)

> > Another concern I have about this fix in 2.5.6 is that there is risk
> > the change is not backward compatible with earlier protocol versions.
> > The file list is sent (unsorted and uncleaned) from the sender to the
> > receiver, and each side then sorts and cleans the list.
> > Remember that the files are referred to as an
> > integer index into the sorted file list, and the receiver skips
> > NULL (duplicate) files.
> > I suspect (but haven't checked) that if a 2.5.5 receiver is talking to
> > a 2.5.6 sender then 2.5.5 will send the index for the 3rd file, which
> > will be null_file on 2.5.6.
> FYI, I just ran a test, and indeed, this causes a seg fault.  I'm
> working up a patch.

I initially thought the file deletion is done by the sending site,
before sending the integer index list to the receiving rsync.. The
problem is more complex than it initially seemed.

rsync2.5.5 to 2.5.6 could generally request either the last _or_ last-1
file, depending on the files in the tree [last-1 for e.g., when given 4
source trees with a missing correspondending file in tree2].

> This also means that if we change which file gets removed (switching
> back to leaving the last name) we'd need to bump the protocol number
> and add some compatibility code for older versions.  Ick.

Since there are some problems with this issue, an increased pid could be
a good idea.

	- thomas