Re: [PATCH] --omit-dir-changes, qsort<>mergesort issues

2006-06-12 Thread Dirk Pape
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

Re: bugfix: indeterministic file choice from multiple sources

2004-09-11 Thread Dirk Pape
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&#x

Re: bugfix: indeterministic file choice from multiple sources

2004-08-26 Thread Dirk Pape
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

Re: bugfix: indeterministic file choice from multiple sources

2004-08-26 Thread Dirk Pape
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

Re: bugfix: indeterministic file choice from multiple sources

2004-08-25 Thread Dirk Pape
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,

Re: bugfix: indeterministic file choice from multiple sources

2004-08-25 Thread Dirk Pape
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?

bugfix: indeterministic file choice from multiple sources

2004-08-24 Thread Dirk Pape
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

Re: rsync-bugs and unclear semantics when copying multiple source-dirs to one target

2003-11-25 Thread Dirk Pape
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

Re: bug (filelist) for platforms solaris and darwin (macosx) and *not* linuxi386

2003-10-06 Thread Dirk Pape
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

bug (filelist) for platforms solaris and darwin (macosx) and *not* linuxi386

2003-09-28 Thread Dirk Pape
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