Hello,
--Am 12. Juni 2006 14:11:59 -0400 schrieb Matt McCutchen
<[EMAIL PROTECTED]>:
Separately, we should look into stable sorting. Maybe, instead of
replacing qsort with another sorting function, we can just keep an
indication of the original order somewhere and use this order to break
tie
Hello,
--Am Mittwoch, 25. August 2004 8:44 Uhr +0200 schrieb Dirk Pape
<[EMAIL PROTECTED]>:
Since in our scenario using rsync we rely on deterministic behaviour, we
patched rsync to use mergesort always for composing the file list. For
systems without a mergesort system call (most os
Hello Paul,
--Am Mittwoch, 25. August 2004 16:59 Uhr +0200 schrieb Paul Slootman
<[EMAIL PROTECTED]>:
In the meantime I'm curious about the relative memory usage of qsort
vs. mergesort. I'd hate rsync's memory usage to go up again.
as far as I am informed (I am not a profi in complexity)
mergeso
Hello Paul,
--Am Mittwoch, 25. August 2004 16:59 Uhr +0200 schrieb Paul Slootman
<[EMAIL PROTECTED]>:
Ah, so you were also lying when you said that the same file existed at
more than one source; the fileNAME is the same, but the file itself is
different.
I would prefer to say that I was mistaking
Hello Wayne,
--Am Mittwoch, 25. August 2004 9:03 Uhr -0700 schrieb Wayne Davison
<[EMAIL PROTECTED]>:
What would you think of a tie-break for identical names that depended on
some other attribute of the files? Such as newest file wins? That
would be quite easy to add and would be deterministic,
Hallo Paul,
--Am Mittwoch, 25. August 2004 10:03 Uhr +0200 schrieb Paul Slootman
<[EMAIL PROTECTED]>:
What I'm wondering is why it's a problem that the same file is
"randomly" copied from one of a number of sources, if indeed it is the
same file. The resulting destination will be the same, right?
Hello,
some time ago I reported a bug, where we saw indeterministic behaviour of
rsync (all versions since 2.5), when having the same file appearing in
multiple sources. Sometimes the file in the first source was copied, other
times the file was copied from one of the other sources.
The attache
t your options are:
Fix rsync to support this behaviour.
I would like to take a quick look to tis first option you mentioned, before
I conider the others.
Do you have and can you send me some API-documentation for the flist
module, which I believe is the one, I have to modify.
Thanks,
Dir
r directly?
Thanks,
Dirk.
--
Dr. Dirk Pape (Leiter des Rechnerbetriebs und IT-Verantwortlicher)
Fachbereich Mathematik und Informatik der FU Berlin
Takustr. 9, 14195 Berlin
Tel. +49 (30) 838 75143, Fax. +49 (30) 838 75190
--Am Sonntag, 28. September 2003 13:19 Uhr +0200 schrieb Dirk Pape
<[EM
I have found a nasty bug when a file, which is in some of many sources,
shall be copied to a target.
The linux-Version works well but rsync 2.5.{2|5|6} under solaris9 (gcc
2.95.3) and darwin (gcc 3.1) do not. The decision which file (out of which
src) shall be copied depends on the number of sr
10 matches
Mail list logo