Harald Amtmann wrote at about 19:29:07 +0100 on Monday, December 7, 2009:
 > So, for anyone who cares (doesn't seem to be anyone on this list who 
 > noticed), I found this post from 2006 stating and analyzing my exact problem:

You are assuming something that is not true...

 > 
 > http://www.topology.org/linux/backuppc.html
 > On this site, search for "Design flaw: Avoidable re-transmission of massive 
 > amounts of data."
 > 
 > 
 > For future reference and archiving, I quote here in full:
 > 
 > "2006-6-7:
 > During the last week while using BackupPC in earnest, I have
 > noticed a very serious design flaw which it totally avoidable by
 > making a small change to the software. First I will describe the
 > flaw with an example.
 
.... details snipped....

> 
 > The design flaw here is crystal clear. Consider a single file
 > home1/xyz.txt. The authors has designed the BackupPC system so that
 > the file home1/xyz.txt is sent in full from client1 to server1
 > unless 
 > 
.... details snipped....
 > 
 > The cure for this design flaw is very easy indeed, and it would
 > save me several days of saturated LAN bandwidth when I make
 > back-ups. It's very sad that the authors did not design the
 > software correctly. Here is how the software design flaw can be
 > fixed. 

This is an open source project -- rather than repetitively talking
about "serious design flaws" in a very workable piece of software (to
which I believe you have contributed nothing) and instead of talking
about how "sad" it is that the authors didn't correct it, why don't
you stop complaining and code a better version.

I'm sure if you produce a demonstrably better version and test it
under a range of use-cases to validate its robustness that people
would be more than happy to use your fix for this "serious" design flaw.

And you win a bigger bonus if you do this all using tar or rsync
without the requirement for any client software of any other remotely
executed commands...

 > The above design concept would make BackupPC much more efficient
 > even under normal circumstances where the variable
 > $Conf{RsyncShareName} is unchanging. At present, rsyncd will only
 > refrain from sending a file if it is present in the same path in
 > the same module in a previous full back-up. If server1 already has
 > the same identical file in any other location, the file is sent by
 > rsyncd and then discarded after it arrives.

It sounds like you know what you want to do so start coding and stop
complaining...

 > If the above serious design flaw is not fixed, it will not do much
 > harm to people whose files are rarely changing and rarely
 > moving. But if, for example, you move a directory tree from once
 > place to another, BackupPC will re-send the whole lot across the
 > LAN, and then it will discard the files when they arrive on the
 > BackupPC server. This will keep on happening until after you have
 > made a full back-up of the files in the new location.  "

No one is stopping you from fixing this "serious design flaw" which
obviously is not keeping the bulk of us users up at night worrying.

And for the record, I don't necessarily disagree with you that there
are things that can be improved but your attitude is going to get you
less than nowhere. Also, the coders are hardly stupid and there are
good reasons for the various tradeoffs they have made that you would
be wise in trying to understand before disparaging them and their
software.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/