How the DST Change can adversely affect FAT filesystems

May 20th, 2026 · +*Andrew Tridgell* + *1998-11-09* +

rsync: error writing 4 unbuffered bytes - exiting: Broken pipe
+rsync error: error in rsync protocol data stream (code 12) at io.c(463)
+
rsync: connection unexpectedly closed (24 bytes read so far)
+rsync error: error in rsync protocol data stream (code 12) at io.c(342)
+
ssh remotesystem /bin/true > test.dat
--delete-delay
--delete-after
--relative
ssh host 'echo $PATH'
rsync -av host:'a long filename' /tmp/
rsync -av host:'"a long filename"' /tmp/
+rsync -av host:'a\ long\ filename' /tmp/
+rsync -av host:a\\\ long\\\ filename /tmp/
rsync -av host:a?long?filename /tmp/
#!/bin/sh
+rsync "$@"
+e=$?
+if test $e = 24; then
+    exit 0
+fi
+exit $e

+
+

+
+
rsync@lists.samba.org
+touch -d '01:00 13-apr-03' /tmp/cmpfile
+find . -type f ! -newer /tmp/cmpfile | shifttime.pl 3600
+
+#!/usr/bin/perl
+use strict;
+
+my $offset = shift() + 0;
+die "Usage: $0 OFFSET_SECONDS\n" unless $offset;
+
+while (<>) {
+    chomp;
+    my $mtime = (stat $_)[9];
+    next unless $mtime;
+    $mtime += $offset;
+    utime $mtime, $mtime, $_;
+}
+

+
+

+
+

+
+

+
+

+One little known feature of rsync is the fact that when run over a
+remote shell (such as rsh or ssh) you can give any shell command as
+the remote file list. The shell command is expanded by your remote
+shell before rsync is called. For example, see if you can work out
+what this does:
+
+	rsync -avR remote:'`find /home -name "*.[ch]"`' /tmp/
+
+note that that is backquotes enclosed by quotes (some browsers don't
+show that correctly).
+
ssh middle ssh target uptime
rsync -av -e "ssh middle ssh" target:/src/ /dest/
Host target
+  ProxyCommand nohup ssh middle nc -w1 %h %p
+  User target_user
+
rsync -av /src/ target:/dest/
Host target
+  HostName localhost
+  Port 2222
+  HostKeyAlias target
+  User target_user
+
ssh -fN -l middle_user -L 2222:target:22 middle
rsync -av target:/src/ /dest/
RSYNC_CONNECT_PROG='ssh -l middle_user middle nc %H 873' \
+    rsync daemonuser@target::module/src/ /dest/
ssh -fN -l middle_user -L 8873:target:873 middle
rsync -av --port 8873 localhost::module/src/ dest/
+rsync -av rsync://localhost:8873/module/src/ dest/

+rsync: error writing 4 unbuffered bytes - exiting: Broken pipe
+rsync error: error in rsync protocol data stream (code 12) at io.c(463)
+

+rsync: connection unexpectedly closed (24 bytes read so far)
+rsync error: error in rsync protocol data stream (code 12) at io.c(342)
+

+echo hi | ssh HOST cat
+ssh HOST rsync --version
+

+rsync -av --rsync-path=/some/path/rsync-debug HOST:SOURCE DEST
+rsync -av --rsync-path=/some/path/rsync-debug SOURCE HOST:DEST
+

+ulimit -c unlimited
+strace -f -t -s 1024 -o /tmp/rsync-$$.out rsync --daemon --no-detach
+

+rsync: connection unexpectedly closed (24 bytes read so far)
+rsync error: error in rsync protocol data stream (code 12) at io.c(342)
+
postmaster
samba.org
+From:   "Mike McHenry" 
+Subject: Rsync 2.3.1 WinNT binaries and instructions available
+Date:   Fri, 15 Oct 1999 02:53:30 +1000
+
+Hello all,
+
+I have created Windows NT binaries for rsync 2.3.1 and have decided to make
+them available for others to download. These binaries have been tested on
+Windows NT Server 4.0 SP5 and WILL run in daemon mode if you follow my
+instructions below. I make no guarantees about these binaries, they have
+however been working for me for weeks on several NT machines.
+
+Binaries at ftp://ftp.minn.net/usr/mmchen/
+
+Instructions for running in daemon mode:
+
+1. You will need two files, rsync.exe and cygwin1.dll. Place rsync.exe
+anywhere you like (I chose c:\program files\rsync\rsync.exe) and put
+cygwin1.dll in c:\winnt\system32
+
+2. You will need a program from the NT Server resource kit called
+srvany.exe. This program allows you to run any executable as a service. If
+you simply install the entire service pack it will be located in c:\ntreskit
+
+3. Create a service for rsync by typing the following:
+  instsrv Rsync "C:\ntreskit\srvany.exe"
+
+4. You should now have a new service called Rsync and you can verify by
+looking in Start->Control Panel->Services DON'T START IT YET!
+
+5. If you want to run rsync in daemon mode you will need a configuration
+file. Here is the one I use, call it rsyncd.conf and place it in the same
+directory as rsync (C:\Program files\rsync\rsyncd.conf)
+  use chroot = false
+  strict modes = false
+  hosts allow = *
+
+  [backup]
+     path = /
+     read only = yes
+     list = no
+
+This example configuration will make one big anonymous anonymous rsync area
+available, I use this to backup my NT machines from a central Unix machine.
+This configuration might not be ideal for you, change to suit your tastes.
+The first two lines are important for rsync to work on Windows NT however.
+
+6. You are going to need to hack some keys in the registry to make it work.
+Don't do this unless you are comfortable with the changes! Run regedit32 and
+add the following keys and values (quotation marks ARE IMPORTANT):
+  HKEY_LOCAL_MACHINE->SYSTEM->CurrentControlSet->Services->Rsync
+    Edit->Add Key->  Key Name: Paramaters
+    Edit->Add Value->  Value Name: AppDirectory  Value: "C:\programfiles\rsync"
+    Edit->Add Value->  Value Name: Application  Value: "C:\programfiles\rsync\rsync.exe"
+    Edit->Add Value->  Value Name: AppParamters  Value: --config="C:\programfiles\rsync\rsyncd.conf" --daemon
+
+7. That's it, you should be able to start and stop the rsync service at will
+using the Services Control Panel. When running with the above configuration
+you should be able to test by attempting to telnet to port 873 from a remote
+machine.
+  telnet rsync.server.com 873 (replacing rsync.server.com with your own
+server's address)
+You should get a connection to the rsync daemon running on your NT box.
+
+8. If you have problems you are on your own, sorry, I have enough to do :) I
+would suggest triple-checking your spelling on EVERYTHING (filenames,
+configs, reg keys). If you have any comments or suggestions I would be happy
+to hear them at mmchen@minn.net.
+
+Mike McHenry
+ Systems Administrator
+ MinnNet Communications, Inc.
+
mbp@samba.org

+
+      

+	By way of background, I have been the maintainer of rsync for
+	about a year, and I wrote the 
+
+      

+	I have tried to respond to all the issues raised on the list
+	recently, but possibly have missed some.  After putting many
+	hours into rsync I suppose I am quite fond of it and may be a
+	little biased, but I think I also know its strengths and
+	problems more than most.
+      
+      

+	If there are issues ommitted by this document, or if you think
+	the answers are incomplete, unbalanced, or incorrect, then
+	please mail 
+
+
+    
+      Background
+
+      
+      
+	The rsync algorithm
+
+	

+	  rsync is really two independent but related ideas: the
+	  
+	
+	

+	  The rsync algorithm is described in detail in the ANU
+	  Technical Report included with the distribution and on the
+	   web site.
+	  

+
+	
+	  Briefly, the rsync algorithm provides an efficient means to
+	  transfer a file 
+
+	

+	  The algorithm could be embodied in other forms and uses than
+	  the rsync program.  Indeed, the algorithm has been
+	  reimplemented in programs other than rsync itself: in other
+	  languages (Rexx, CAML, Java), in a C library (
+
+	

+	  rsync deltas are much more efficient than diffs, for several
+	  reasons: most importantly, useful diff formats include
+	  context lines, which are wasted information.  rsync gets the
+	  same benefit of making sure that the change is applied to a
+	  compatible version of the file, but in a much more efficient
+	  way.  diffs suffer from being human-readable and therefore
+	  verbose, and cannot handle binary files.  Both can be
+	  transparently compressed.  diffs are an invaluable tool for
+	  software development, but not ideal for distribution of
+	  deltas.
+	

+      
+
+
+      
+      
+	
+	  The rsync mirroring program is similar in functionality to
+	  other tools such as 
+
+	
+	  In general, rsync is substantially faster than other
+	  tools, because it uses delta compression, and because the
+	  protocol is designed to be efficient both in traffic and
+	  round trips.  rsync can use 
+
+	

+	  rsync has the important property that it is generally
+	  idempotent: repeated runs of rsync, even if interrupted,
+	  make the contents of the destination machine converge
+	  towards those of the source machine.
+
+	

+	  Unlike wget and ftpmirror, rsync must be installed on both
+	  the client and the server.  It uses its own protocol, rather
+	  than HTTP or FTP.  This is probably the biggest practical
+	  drawback at the moment: one cannot use rsync from arbitrary
+	  web sites, but only from systems  that have specifically
+	  chosen to support it.  On the other hand, many important
+	  sites for free software do now support rsync, and the
+	  developers see them as an important constituency to support.
+
+	

+	  rsync can tunnel through a proxy server that supports
+	  
+	  rsync can run as a daemon, similar to an /etc/rsyncd.conf file.  The
+	  archetypal use is to offer public, anonymous, read-only
+	  access to a software archive but as with 
+
+	

+	  rsync can also run across a tunnel program such as 
+	
+	

+	  rsync may also be used locally, which is a degenerate case
+	  with client and server connected across a unix-domain or
+	  localhost socket.
+	
+
+	

+	  rsync runs on many varieties of Unix under both gcc and
+	  native compilers, and also under Cygwin on Microsoft
+	  platforms.  There is somebody working on a VMS port.
+	

+      
+
+
+      
+
+      
+	
+	  
+	  
+	  
+	  For example, you can imagine the server calculating and
+	  caching the checksums, or the client calculating the delta
+	  once and then sending it over UDP multicast to several
+	  destinations, or uuencoded in email.  Neither of these would
+	  be straightforward to implement in the rsync codebase, but
+	  all can be done with rdiff.
+
+      
+
+
+      
+	
+	   program, which
+	  is a prototype of transparent integration of delta
+	  compression into HTTP.
+	
+
+	
+	  rproxy implements delta compression of arbitrary HTTP
+	  content, whether dynamic or static.  For example, rproxy
+	  gives very good compression on repeated visits to portal
+	  sites such as Slashdot, since it can transmit only the
+	  sections of the page modified since last time it was
+	  viewed.  Regular HTTP caches, by contrast, must either hit
+	  on the whole page, or reload the whole page, and therefore
+	  do poorly on template-based dynamic content.
+
+	

+	  rproxy adds compatible extensions to HTTP headers, and can
+	  pass through HTTP caches.  It requires upstream and
+	  downstream support, which at the moment means two
+	  installations of rproxy, but in the future could conceivably
+	  be integrated into Mozilla, Squid, Apache and similar
+	  programs.  
+
+	

+	  rproxy is packaged in Debian and is moderately useful for
+	  people with slow links.
+
+	

+	  rproxy is not HTML-specific, but HTML is by far the most
+	  common case of dynamic HTTP content that can be
+	  delta-compressed.  However, HTML documents tend to be fairly
+	  small, and as connectivity improves they're becoming of
+	  decreasing interest as a compression problem.
+
+	

+	  (My personal interest in this project declined significantly
+	  when I went from a 56k6 modem to ADSL at home.  I realize
+	  many people in the world still have slow connections.)
+
+	

+	  There are some Internet Drafts from Jeffrey Mogul and others
+	  that add similar delta compression based on the server
+	  storing all possible deltas.  Last time I looked, there did
+	  not seem much interest in wide adoption of these proposals.
+
+	

+	  Documenting a protocol extension to the standard expected by
+	  an RFC can be a lot of work.  A beginning on this work has
+	  been made for rproxy, but more experiments with the
+	  implementation are needed before proposal as a standard.
+
+	

+	  rproxy is not being actively developed at the moment.
+	  Obviously I cannot answer why every programmer in the world
+	  does not work on this.  Personally I think that developing
+	  rsync itself, and then librsync/rdiff, is likely to be more
+	  useful; I suspect other people interested in working in this
+	  area might have similar thoughts.  
+
+	

+	  I don't think there are any problems in the code or project
+	  that would actively prevent anybody from working on it.  I'd
+	  be happy to hand over maintenance to somebody else.  Ben
+	  Elliston has expressed interest in looking after it in the
+	  last couple of months, and possibly it will be more active
+	  in the future.
+      
+
+      
+
+      
+	Introduction to Debian
+
+	

+	  Debian is a free operating system developed by the
+	  cooperation of people all over the world.  The most
+	  important relation of rsync to Debian is copying of software
+	  packages from developers to distribution servers to end
+	  users.
+	
+
+	
+	  Many Debian users get their software by internet download
+	  from a public server, rather than pre-installed on a machine
+	  or on CD-ROM.
+	
+
+	
+	  Debian software archives include both software source,
+	  binary packages for various architectures, and index
+	  metadata, primarily the 
+
+	

+	  Because of Debian's community development process, new
+	  packages are released very often.  On a typical day in
+	  Debian's 
+
+	

+	  Debian is quite different from other software distributions
+	  in shipping so many packages so frequently.  The BSDs (as I
+	  understand it) base most of their development out of a CVS
+	  or CVSup tree, which inherently distributes coarse-grained
+	  deltas.  Proprietary systems make binary releases, but much
+	  less frequently.  Possibly the development branches of other
+	  distributions, such as Redhat "Rawhide" and Mandrake
+	  "Cooker" are similar.
+	  

+      
+
+
+
+
+      
+	apt-proxy 
+      
+		is a caching proxy for Debian archives.  It appears as an HTTP
+	server to apt clients, and uses rsync, http, or ftp to connect
+	to an upstream server.  
+
+      

+	Because rsync is less efficient than HTTP for transferring
+	compressed files, 
+	
+	The original apt-proxy was written by Paul 'Rusty' Russel.
+	The current maintainer is Chris Halls.
+      

+    
+  
      
+
+    
+
+    
+      Open Issues
+
+
+      
+	
+	  
+
+	
+	  Although delta compression is not possible, rsync is still a
+	  very useful tool for mirroring compressed files.  The
+	  efficient network protocol mean that it will generally be
+	  slightly faster and use less traffic than HTTP or FTP.
+
+	

+	  There is a patch called 
+	  I believe that this will merge into the upstream 
+	  The scheme for containing changes is not specific to rsync,
+	  and might also be useful with 
+	  This scheme relies on the output file being determined only
+	  by the input file.  As far as I know compression schemes
+	  like gzip, lzw, and bzip2 are deterministic in this way.
+	  (GnuPG, for example, is not, since it uses a random session
+	  key.)
+
+	

+	  Incidentally this would allow more efficient deltas between
+	  Debian ISO images.
+	

+
+	
+	  Alternatively, you could distribute an uncompressed package
+	  tree that would rsync efficiently, but since the gzip patch
+	  should merge soon this seems unnecessary.
+
+	

+	  There is also the interesting possibility of using
+	  
+	  It could be possible to make an equivalent patch to
+	  
+	  A patch to gzip which implements this behaviour is available
+	  from rsync CVS.
+      
+
+
+
+      
+	
+	  If it is, then I think we should fix the problems, rather
+	  than invent a new system from scratch.  I think the
+	  scalability problems are accidents of the current codebase,
+	  rather than anything inherent in the design.
+	

+      
+
+
+      
+      
+	
+	  Some projects (Apache 2.0, Mozilla, ...) choose to do this;
+	  some concentrate on piecemeal improvement (Linux).
+
+	
+	  As Joel Spolsky recently observed, throwing the code out to
+	  start from scratch always seems like a nice idea, but rarely
+	  works out.  Essentially you are opting for the devil you
+	  don't know, but he definitely exists.
+
+	

+	  Having dealt with some fairly crufty old code I sometimes
+	  feel like doing this in rsync, but I can also see the
+	  arguments against it.  Starting from a new codebase would
+	  bring in plenty of new bugs (including security bugs),
+	  orphan existing users, and halt progress until it caught up
+	  to the same level.  It would require carefully documenting
+	  all the existing internal protocols and behaviours, which is
+	  a nice idea but not clearly a good use of the developers'
+	  time.
+
+	

+	  If you throw out the code, you have the questions of whether
+	  or not to keep the current network protocol, and whether or
+	  not to keep the current command-line option.
+
+	

+	  Not being able to talk to old remote versions would be a
+	  real pain, and would certainly slow adoption.  (Think of how
+	  unpopular SSH2 was when it wanted to be incompatible with
+	  SSH1, but use the same TCP port.)  On the other hand,
+	  keeping the same network protocol limits your ability to
+	  redesign things.
+
+	
+	

+	  There is some cruft in the command line syntax, but throwing
+	  it out would also break everybody's scripts, mental maps,
+	  and documentation.
+
+
+	

+	  Possibly rsync 3.0 will be largely rewritten.  
+
+      
+
+
+      
+	
+	  Debian's goals for rsync have to be balanced against the
+	  requirements of other users (including the mirror sites that
+	  distribute Debian) and the limited development resources.
+
+	

+	  As of April 2002, the 2.5.5 release is current and 2.5.6 is
+	  pending.  These versions seem to work quite well and we
+	  encourage people to upgrade from stable 2.4.6 and previous
+	  versions.  It is very important to the developers to
+	  establish a stable base release before starting out on new
+	  development.
+	

+
+	
+	  A number of enhancements are planned for the 2.6 series.
+	  Some of them are discussed below, and more details can be
+	  found in the 
+	  If you want rsync to progress faster, the best thing you can
+	  do is find reproducible failure cases and report them well,
+	  or to help us write a regression test suite.
+
+	

+	  Nobody is very actively working on rproxy or librsync as far
+	  as I know.  Personally at the moment I feel supporting rsync
+	  itself is more useful.
+      
+
+
+
+      
+      
+	
+	  Goswin Brederlow has a nice proposal that allows rsync
+	  compression using a regular HTTP server.  It depends only
+	  upon rsyncable archives, and development of new client and
+	  support programs.
+
+	

+	  The idea, as I understand it, is that the checksums for each
+	  package should be pre-calculated and stored on the HTTP
+	  server along with the files they describe.  (The checksum
+	  files should be on the order of a thousand times smaller
+	  than the archive file.)
+
+	

+	  The client program will download the checksum file over HTTP
+	  if it exists.  The client can then search for common blocks
+	  in the local file, and therefore determine what new regions
+	  it must fetch from the server.  The client then sends an
+	  HTTP request using the optional 
+	  This scheme has the great advantage that the server is
+	  entirely passive, and only needs to support standard HTTP.
+	  The checksum files can be generated once for each package
+	  either during upload, or by the administrator of a
+	  particular server.
+
+	

+	  (This is not the same as rproxy, which uses a different
+	  encoding and requires upstream support, but can
+	  transparently compress any request without requiring
+	  signature files on the server.)
+
+	

+	  This scheme could be fairly easily built on top of rdiff or
+	  librsync.
+
+	

+	  I think this sounds like a very promising scheme.  I think
+	  rsync might still be better for people who want to copy
+	  large trees, but for users apt-getting single packages this
+	  would be a simple way to get delta-compression in, pending
+	  only --rsyncable files.
+
+
+	

+	  I'm not sure if all HTTP servers currently handle 
+	  Because it requires a special client, and special checksum
+	  files stored on the server it has a wider impact than just
+	  using rsync.  It ought to be done in a non-Debian-specific
+	  way.  Rather than adding knowledge about the deltas into
+	  apt-get itself, we ought to make a separate tool which
+	  downloads a delta over HTTP.
+
+      
+
+
+
+
+       
+	 rsync only compares files with the exact same
+	   name
+
+	 

+	   Even for uncompressed files, rsync will not currently try to
+	   use 
+	   Paul Russell has contributed a patch which adds a heuristic
+	   to detect this.  It will probably be merged in 2.6.
+	 

+       
+
+
+       
+	 
+	   rsync traverses the entire directory tree before it begins
+	   copying files.  On machines with little virtual memory and a
+	   lot of files to copy this can be a problem.
+
+	 
+	   Some problems in this area have been fixed in the 2.5
+	   series.  Other solutions involving internal restructuring of
+	   the 
+	   We are not likely to change the general approach of
+	   traversing the tree up-front in the near future, because it
+	   is tightly tied to the network protocol.  It might be
+	   attempted in the 3.0 timeframe, but it is not entirely clear
+	   that it is really a problem.
+       
+
+
+
+       
+	 rsync hangs?
+
+	 

+	   There were a number of deadlock bugs in the past.  We
+	   believe they are all fixed in 2.5.5, but would welcome good
+	   bug reports to the contrary.  Some of them were in fact
+	   Linux and Solaris kernel bugs, but they've been fixed by the
+	   relevant parties quite some time ago.
+	 

+       
+
+
+
+       
+	 Reduced network usage is not justified by increased CPU
+	   usage
+	 
+
+	 
+	   The balance point will vary for each administrator.  It is
+	   hard to answer this universally.  The balance is very
+	   different in countries other than the US.
+	 
+
+	 
+	   I suspect CPU cycles are falling in price faster than
+	   network bandwidth, and for many people unused CPU cycles are
+	   wasted but network packets cost money.
+	 
+       
+
+
+
+       
+	 
+	   rsync with --whole-file (to turn off the
+	   delta algorithm and be more comparable to ftp) floods a
+	   100Mbps link.  If you have something faster than that to
+	   your upstream Debian mirror, you're a lucky person.
+	 
+
+	 
+	   It is not inherently impossible to make rsync use
+	   sendfile() and mmap(); it's just that most
+	   people don't need them.  (Apache did not use them by default
+	   either last time I looked, but that doesn't mean it's not
+	   fast enough for most people.)
+	 
+       
+
+
+
+       
+	 rsync is not actively developed
+
+	 
+	   This was a pretty fair accusation a year ago, but I don't
+	   think it is true anymore.  We have made five releases this
+	   year, and the 
+	   Mail is answered promptly.  The web site has been revised
+	   and cleaned.  We're working on a regression test suite, code
+	   cleanup and documentation, and other quality issues.
+
+	 

+	   I'm the most active developer at the moment, but there are a
+	   number of other people with experience in the code who
+	   regularly commit changes or send patches.
+
+	 

+	   The stability expectations of our users require a somewhat
+	   disciplined approach to accepting patches, but I don't think
+	   that's a bad thing.  The goal is to iterate through
+	   
+	   The Debian rsync package maintainer, Phil Hands, has been
+	   somewhat inactive, but apparently he's back now.  Colin
+	   Walters has been helping out.
+
+	 

+	   If you have patches that were dropped, please send them
+	   through again.
+       
+
+
+
+       
+	 Servers should cache deltas
+
+	 

+	   This also smells like premature optimization.  It might be
+	   useful, but it certainly seems less important than some
+	   other tasks.
+       
+
+
+
+       
+	 Possible patent on rsync?
+
+	 

+	   It has been suggested that some uses of rsync may conflict
+	   with a US patent.  I am not sure of the current situation so
+	   I won't comment.  I don't know of any suggestion that the
+	   rsync program as it currently exists infringes any patent.
+	 

+
+	 
+	   I do know that rsync has been in use for many years by large
+	   and small organization with no complaints of patent
+	   infringement.
+	 
+
+	 
+	   I would point out that linked lists, mark-and-copy garbage
+	   collection, and the Tab key are all patented too.  Somebody
+	   who always carefully checked first for software patents
+	   would never write anything at all.
+	 
+
+       
+
+
+       
+	 Debian should store more metadata outside of
+	 the package file
+
+	 
+	   I can see some reasons why this might be a good idea, but
+	   it doesn't seem particularly relevant to rsync either way.
+	 
+       
+
+
+
+       
+	 Debian should distribute diffs or xdeltas
+	   between different versions of their packages
+
+	 
+	   A problem with this is that Debian releases packages very
+	   often, and so the number of delta files is large.  This will
+	   be a problem for mirror sites who cannot carry all of the
+	   delta files for history, although of course the client could
+	   fall back to directly fetching the new package if the
+	   relevant deltas are not present.
+	 
+
+	 
+	   Fetching a series of deltas which update the same area is
+	   less efficient than calculating the deltas directly.
+	 
+
+	 
+	   Although this idea does not seem very practical for people
+	   using 
+      
+      
+	rsync should be used by 
+	
+	

+	  Even if there are few gains from compressing 
+    
+
+    
+    
+    
+      Revision history
+
+      
+

+$Log: rsync-and-debian.sgml,v $
+Revision 1.10  2002/05/14 03:10:09  mbp
+Add note about just transferring Package files.
+
+Revision 1.9  2002/05/14 02:35:43  mbp
+Update notes on apt-proxy based on mail from Chris Halls.
+
+Revision 1.8  2002/04/12 02:04:15  mbp
+More information about Goswin's idea, as I understand it.
+
+Revision 1.7  2002/04/12 01:39:52  mbp
+Lots more details about rproxy.  Thanks to Brian May for prompting me
+to do this.
+
+Revision 1.6  2002/04/12 00:43:06  mbp
+Fix revision history SGML stuff.
+
+Revision 1.5  2002/04/12 00:24:50  mbp
+Fix mailing list name.
+Add revision history.
+	
+	  

+    
+  

+

\ No newline at end of file

diff --git a/rsync-web/rsync-debug b/rsync-web/rsync-debug
new file mode 100644
index 00000000..adb6ee5f
--- /dev/null
+++ b/rsync-web/rsync-debug
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+ulimit -c unlimited
+
+# Some systems have "truss" or "tusc" instead of "strace".
+# The -f option tells strace to follow children too.
+# The -t option asks for timestamps.
+# The -s 1024 option increases the string decoding limit per function call.
+# The -o option tells strace where to send its output.
+strace -f -t -s 1024 -o /tmp/rsync-$$.out rsync "${@}"
diff --git a/rsync-web/rsync_wrapper.pl b/rsync-web/rsync_wrapper.pl
new file mode 100644
index 00000000..b760a977
--- /dev/null
+++ b/rsync-web/rsync_wrapper.pl
@@ -0,0 +1,471 @@
+#      __
+#     /\ \ From the mind of
+#    /  \ \
+#   / /\ \ \_____ Lee Eakin  
+#  /  \ \ \______\       or  
+# / /\ \ \/____  /
+# \ \ \ \____\/ / Wrapper module for the rsync program
+#  \ \ \/____  /  rsync can be found at http://rsync.samba.org/rsync/
+#   \ \____\/ /
+#    \/______/
+
+package Rsync;
+require 5.004;
+
+use FileHandle;
+use IPC::Open3 qw(open3);
+use Carp;
+
+use strict;
+
+=head1 NAME
+
+Rsync - perl module interface to B http://rsync.samba.org/rsync/
+
+=head1 SYNOPSIS
+
+use Rsync;
+
+$obj = Rsync->new(qw(-az C<-e> /usr/local/bin/ssh
+         --rsync-path /usr/local/bin/rsync));
+
+$obj->exec(qw(localdir rhost:remdir))
+         or warn "rsync failed\n";
+
+=head1 DESCRIPTION
+
+Perl Convenience wrapper for B program.  Written for B 2.3.1 but
+should perform properly with most versions.
+
+=cut
+
+# options from the rsync man pae
+###### Boolean flags ######
+# -h, --help                  show this help screen
+# -v, --verbose               increase verbosity
+# -q, --quiet                 decrease verbosity
+# -c, --checksum              always checksum
+# -a, --archive               archive mode
+# -r, --recursive             recurse into directories
+# -R, --relative              use relative path names
+# -b, --backup                make backups (default ~  suffix)
+# -u, --update                update only (don't overwrite newer files)
+# -l, --links                 preserve soft links
+# -L, --copy-links            treat soft links like regular files
+#     --copy-unsafe-links     copy links outside the source tree
+#     --safe-links            ignore links outside the destination tree
+# -H, --hard-links            preserve hard links
+# -p, --perms                 preserve permissions
+# -o, --owner                 preserve owner (root only)
+# -g, --group                 preserve group
+# -D, --devices               preserve devices (root only)
+# -t, --times                 preserve times
+# -S, --sparse                handle sparse files efficiently
+# -n, --dry-run               show what would have been transferred
+# -W, --whole-file            copy whole files, no incremental checks
+# -x, --one-file-system       don't cross filesystem boundaries
+# -C, --cvs-exclude           auto ignore files in the same way CVS does
+#                             RCS SCCS CVS CVS.adm RCSLOG cvslog.* tags TAGS
+#                             .make.state .nse_depinfo *~ #* .#* ,* *.old *.bak
+#                             *.BAK *.orig *.rej .del-* *.a *.o *.obj *.so *.Z
+#                             *.elc *.ln core
+#     --delete                delete files that don't exist on the sending side
+#     --delete-excluded       also delete excluded files on the receiving side
+#     --partial               keep partially transferred files
+#     --force                 force deletion of directories even if not empty
+#     --numeric-ids           don't map uid/gid values by user/group name
+# -I, --ignore-times          don't exclude files that match length and time
+#     --size-only             only use file size when determining if a file
+#                             should be transferred
+# -z, --compress              compress file data
+#     --version               print version number
+#     --daemon                run as a rsync daemon
+#     --stats                 give some file transfer stats
+#     --progress              show progress during transfer
+###### scalar values ######
+#     --csum-length=LENGTH    <=16 bit md4 checksum size
+# -B, --block-size=SIZE       checksum blocking size (default 700)
+#     --timeout=TIME          set IO timeout in seconds
+#     --port=PORT             specify alternate rsyncd port number
+# -e, --rsh=COMMAND           specify rsh replacement
+# -T, --temp-dir=DIR          create temporary files in directory DIR
+#     --compare-dest=DIR      also compare destination files relative to DIR
+#     --exclude-from=FILE     exclude patterns listed in FILE
+#     --include-from=FILE     don't exclude patterns listed in FILE
+#     --config=FILE           specify alternate rsyncd.conf file
+#     --password-file=FILE    get password from FILE
+#     --log-format=FORMAT     log file transfers using specified format
+#     --suffix=SUFFIX         override backup suffix
+#     --rsync-path=PATH       specify path to rsync on the remote machine
+###### array values ######
+#     --exclude=PATTERN       exclude files matching PATTERN
+#     --include=PATTERN       don't exclude files matching PATTERN
+#
+
+=over 4
+
+=item Rsync::new
+
+$obj = new Rsync;
+
+   or
+
+$obj = Rsync->new;
+
+   or
+
+$obj = Rsync->new(@options);
+
+=back
+
+Create an Rsync object.  Any options passed at creation are stored in
+the object as defaults for all future exec call on that object.  Options
+are the same as those in L with the addition of
+--path-to-rsync which can be used to override the hardcoded default of
+/usr/local/bin/rsync, and --debug which causes the module functions to
+print some debugging information to STDERR.
+
+=cut
+
+sub new {
+   my $class=shift;
+
+   # seed the options hash, booleans, scalars, excludes, data,
+   # status, stderr/stdout storage for last exec
+   my $self={
+      # the full path name to the rsync binary
+      'path-to-rsync' => '/usr/local/bin/rsync',
+      # these are the boolean flags to rsync, all default off, including them
+      # in the args list turns them on
+      'flag' => {qw(
+         --archive         0   --backup          0   --checksum          0
+         --compress        0   --copy-links      0   --copy-unsafe-links 0
+         --cvs-exclude     0   --daemon          0   --delete            0
+         --delete-excluded 0   --devices         0   --dry-run           0
+         --force           0   --group           0   --hard-links        0
+         --help            0   --ignore-times    0   --links             0
+         --numeric-ids     0   --one-file-system 0   --owner             0
+         --partial         0   --perms           0   --progress          0
+         --quiet           0   --recursive       0   --relative          0
+         --safe-links      0   --size-only       0   --sparse            0
+         --stats           0   --times           0   --update            0
+         --verbose         0   --version         0   --whole-file        0
+      )},
+      # these have simple scalar args we cannot easily check
+      'scalar' => {qw(
+         --block-size      0   --compare-dest    0   --config            0
+         --csum-length     0   --exclude-from    0   --include-from      0
+         --log-format      0   --password-file   0   --port              0
+         --rsh             0   --rsync-path      0   --suffix            0
+         --temp-dir        0   --timeout         0
+      )},
+      # these can be specified multiple times and are additive, the doc also
+      # specifies that it is an ordered list so we must preserve that order
+      'exclude'     => [],
+      # source/destination path names and hostnames
+      'data'        => [],
+      # return status from last exec
+      'status'      => 0,
+      'realstatus'  => 0,
+      # whether or not to print debug statements
+      'debug'       => 0,
+      # stderr from last exec in array format (messages from remote rsync proc)
+      'err'         => [],
+      # stdout from last exec in array format (messages from local rsync proc)
+      'out'         => [],
+   };
+   if (@_) {
+      &defopts($self,@_) or return undef;
+   }
+   bless $self, $class;
+}
+
+=over 4
+
+=item Rsync::defopts
+
+defopts $obj @options;
+
+   or
+
+$obj->defopts(@options);
+
+=back
+
+Set default options for future exec calls for the object.  See L
+for a complete list of valid options.  This is really the internal
+function that B calls but you can use it too.  Presently there is no way
+to turn off the boolean options short of creating another object, but if it is
+needed and the B guys don't use it, I may add hooks to let + and ++ or a
+leading no- toggle it back off similar to B (the GNU way).
+
+=cut
+
+sub defopts {
+   my $self=shift;
+   my @opts=@_;
+
+   # need a conversion table in case someone uses the short options
+   my %short=(qw(
+      -B  --block-size   -C  --cvs-exclude     -D  --devices   -H  --hard-links
+      -I  --ignore-times -L  --copy-links      -R  --relative  -T  --temp-dir
+      -W  --whole-file   -a  --archive         -b  --backup    -c  --checksum
+      -e  --rsh          -g  --group           -h  --help      -l  --links
+      -n  --dry-run      -o  --owner           -p  --perms     -q  --quiet
+      -r  --recursive    -s  --sparse          -t  --times     -u  --update
+      -v  --verbose      -x  --one-file-system -z  --compress
+   ));
+   while (my $opt=shift @opts) {
+      my $arg;
+      print(STDERR "setting debug flag\n"),$self->{debug}=1,next
+         if $opt eq '--debug';
+      print STDERR "processing option: $opt\n" if $self->{debug};
+      if ($opt=~/^-/) {
+         # handle short opts first
+         if ($opt=~/^-(\w+)$/) {
+            foreach (split '',$1) {
+               print STDERR "short option: -$_\n" if $self->{debug};
+               if (exists $short{'-'.$_}) {
+                  $opt=$short{'-'.$_};
+                  # convert it to the long form
+                  $opt=$short{$opt} if exists $short{$opt};
+                  # handle the 3 short opts that require args
+                  $self->{scalar}{$opt}=shift(@opts),next if (/^[BeT]$/);
+                  # handle the rest
+                  $self->{flag}{$opt}=1,next if exists $self->{flag}{$opt};
+               }
+               carp "$opt - unknown option\n";
+               return undef;
+            }
+         }
+         # handle long opts with = args
+         if ($opt=~/^(--\w+[\w-]*)=(.*)$/) {
+            print STDERR "splitting longopt: $opt ($1 $2)\n" if $self->{debug};
+            ($opt,$arg)=($1,$2);
+         }
+         # handle boolean flags
+         $self->{flag}{$opt}=1,next if exists $self->{flag}{$opt};
+         # handle simple scalars
+         $self->{scalar}{$opt}=($arg || shift @opts),next
+            if exists $self->{scalar}{$opt};
+         # handle excludes
+         if ($opt eq '--exclude') {
+            $arg||=shift @opts;
+            # if they sent a reset, we will too
+            $self->{exclude}=[],next if $arg eq '!';
+            # otherwise add it to the list
+            push @{$self->{exclude}},$arg;
+            next;
+         }
+         # to preserve order we store both includes and excludes in the same
+         # array.  We use the leading '+ ' (plus space) trick from the man
+         # page to accomplish this.
+         if ($opt eq '--include') {
+            $arg||=shift @opts;
+            # first check to see if this is really an exclude
+            push(@{$self->{exclude}},$arg),next if $arg=~s/^- //;
+            # next see if they sent a reset, if they did, we will too
+            $self->{exclude}=[],next if $arg eq '!';
+            # if it really is an include, fix it first, since we use exclude
+            $arg='+ '.$arg unless $arg=~/^\+ /;
+            push @{$self->{exclude}},$arg;
+            next;
+         }
+         # handle our special case to override hard-coded path to rsync
+         $self->{'path-to-rsync'}=($arg || shift @opts),next
+            if $opt eq '--path-to-rsync';
+         # if we get this far nothing matched so it must be an error
+         carp "$opt - unknown option\n";
+         return undef;
+      } else { # must be data (source/destination info)
+         print STDERR "adding to data array: $opt\n" if $self->{debug};
+         push(@{$self->{data}},$opt);
+      }
+   }
+   1;
+}
+
+=over 4
+
+=item Rsunc::exec
+
+exec $obj @options or warn "rsync failed\n";
+
+   or
+
+$obj->exec(@options) or warn "rsync failed\n";
+
+=back
+
+This is the function that does the real work.  Any options passed to this
+routine are appended to any pre-set options and are not saved.  They effect
+the current execution of B only.  It returns 1 if the return status was
+zero (or true), if the B return status was non-zero it returns undef and
+stores the return status.  You can examine the return status from rsync and
+any output to stdout and stderr with the functions listed below.
+
+=cut
+
+sub exec {
+   my $self=shift;
+   my @cmd=($self->{'path-to-rsync'});
+
+   foreach (sort keys %{$self->{flag}}) {
+      push @cmd,$_ if $self->{flag}{$_};
+   }
+   foreach (sort keys %{$self->{scalar}}) {
+      push @cmd,$_.'='.$self->{scalar}{$_} if $self->{scalar}{$_};
+   }
+   foreach (@{$self->{exclude}}) {
+      push @cmd,'--exclude='.$_;
+   }
+   foreach (@{$self->{data}}) {
+      push @cmd,$_;
+   }
+   push @cmd,@_ if @_;
+   print STDERR "exec: @cmd\n" if $self->{debug};
+   my $in=FileHandle->new; my $out=FileHandle->new; my $err=FileHandle->new;
+   my $pid=eval{ open3 $in,$out,$err,@cmd };
+   if ($@) {
+      $self->{realstatus}=0;
+      $self->{status}=255;
+      $self->{err}=[$@,"Execution of rsync failed.\n"];
+      return undef;
+   }
+   $in->close; # we don't use it and neither should rsync (at least not yet)
+   $self->{err}=[ $err->getlines ];
+   $self->{out}=[ $out->getlines ];
+   $err->close;
+   $out->close;
+   waitpid $pid,0;
+   $self->{realstatus}=$?;
+   $self->{status}=$?>>8;
+   return undef if $self->{status};
+   return 1;
+}
+
+=over 4
+
+=item Rsync::status
+
+$rval = status $obj;
+
+   or
+
+$rval = $obj->status;
+
+=back
+
+Returns the status from last B call right shifted 8 bits.
+
+=cut
+
+sub status {
+   my $self=shift;
+   return $self->{status};
+}
+
+=over 4
+
+=item Rsync::realstatus
+
+$rval = realstatus $obj;
+
+   or
+
+$rval = $obj->realstatus;
+
+=back
+
+Returns the real status from last B call (not right shifted).
+
+=cut
+
+sub realstatus {
+   my $self=shift;
+   return $self->{realstatus};
+}
+
+=over 4
+
+=item Rsync::err
+
+$aref = err $obj;
+
+   or
+
+$aref = $obj->err;
+
+=back
+
+Returns an array or a reference to the array containing all output to stderr
+from the last B call.  B sends all messages from the remote
+B process to stderr.  This functions purpose is to make it easier for
+you to parse that output for appropriate information.
+
+=cut
+
+sub err {
+   my $self=shift;
+   return(wantarray ? @{$self->{err}} : $self->{err});
+}
+
+=over 4
+
+=item Rsync::out
+
+$aref = out $obj;
+
+   or
+
+$aref = $obj->out;
+
+=back
+
+Similar to the B function, this returns an array or a reference to the
+array containing all output to stdout from the last B call.  B
+sends all messages from the local B process to stdout.
+
+=cut
+
+sub out {
+   my $self=shift;
+   return(wantarray ? @{$self->{out}} : $self->{out});
+}
+
+=head1 Author
+
+Lee Eakin Eleakin@nostrum.comE
+
+=head1 Credits
+
+Gerard Hickey                             C
+
+Russ Allbery                              C
+
+Graham Barr                               C
+
+Andrew Tridgell and Paul Mackerras        C
+
+John Steele   Esteele@nostrum.comE
+
+Philip Kizer  Epckizer@nostrum.comE
+
+Larry Wall                                C
+
+I borrowed many clues on wrapping an external program from the PGP modules,
+and I would not have had such a useful tool to wrap except for the great work
+of the B authors.  Thanks also to Graham Barr, the author of the libnet
+modules and many others, for looking over this code.  Of course I must mention
+the other half of my brain, John Steele, and his good friend Philip Kizer for
+finding B and bringing it to my attention.  And I would not have been
+able to enjoy writing useful tools if not for the creator of the B
+language.
+
+=head1 Copyrights
+
+      Copyleft (l) 1999, by Lee Eakin
+
+=cut
+
+1;
diff --git a/rsync-web/security.html b/rsync-web/security.html
new file mode 100644
index 00000000..fedcffcb
--- /dev/null
+++ b/rsync-web/security.html
@@ -0,0 +1,284 @@
+
+
+
+rsync
+
+
+
+
+Rsync Security Advisories
+
+You should install a security fix for rsync when the rync you are running is:

+older than 3.2.5 and pulling from an untrusted server
+
older than 3.2.5 and using the bundled zlib
+
older than 3.1.3 with --xattrs enabled
+
older than 3.1.3 with a writable rsync daemon
+
older than 2.6.6
+
+
+

+Improved file-list validation in 3.2.5
+August 14th, 2022
+
+If you are running an rsync older than 3.2.5 and pulling files from an
+untrusted server, upgrade to 3.2.5 to get some added file-list validation rules
+that should prevent the sender from sneaking in extra top-level arguments
+and/or including files/dirs that should have been filtered out by the client's
+filter rules. Fixes CVE-2022-29154.
+
+

+Zlib memory corruption bug in rsync 2.6.6 - 3.2.4
+August 14th, 2022
+
+If your rsync is configured to use the bundled zlib, you should upgrade to
+3.2.5 which contains the official zlib fix for a buffer overrun bug that was
+detailed in CVE-2022-37434. While you're at it, be sure to update your system's
+zlib.
+
+

+Zlib memory corruption bug in rsync 2.6.6 - 3.2.3
+April 15th, 2022
+
+If your rsync is configured to use the bundled zlib, you should upgrade to
+3.2.4 which contains the official zlib fix for a memory corruption bug that was
+detailed in CVE-2018-25032. While you're at it, be sure to update your system's
+zlib.
+
+

+File-list validation in 3.1.3
+January 28st, 2018
+
+If you are using a version of rsync older than 3.1.3 as a client and
+receiving xattrs from an rsync server that you might not fully trust, a
+malicious (modified) server could send a non-null-terminated xattr name to
+overflow the xattr read buffer.
+
+
If you are running a writable rsync daemon older than 3.1.3, you should add
+a rule "refuse options = protect-args" if you don't fully trust the users who
+are sending you files.
+
+

+File-list validation in 3.1.2
+December 21st, 2015
+
+If you're using a version of rsync older than 3.1.2 as a client and
+receiving files from an rsync server that you might not fully trust, this
+version adds extra checking to the file list to prevent the sender from
+tweaking the paths and/or the transfer requests in a way that could cause
+a file to be received outside the transfer destination.
+
+

+Xattr security fix in 3.0.2
+April 8th, 2008
+
+If you're using a version of rsync from 2.6.9 to 3.0.1 that has extended
+attribute (xattr) support enabled, you should upgrade to 3.0.2 to avoid a
+potential buffer overflow problem.  All 3.x versions have the potential to
+support xattrs (depending on OS availability and the configure options used),
+but version 2.6.9 had to be patched for this support.  You can run the command
+"rsync --version" and look for the string "xattrs" (as long as it is not
+"no xattrs") to see if your rsync is affected.
+
+
For those running affected versions, there is
+a
+patch with the fix available.
+
+
Those running a writable rsync daemon can opt to refuse the "xattrs" option
+as a way to avoid the problem without an upgrade:
+
+
refuse options = xattrs
+
+(If you already refuse options, be sure to append "xattrs" to your existing
+config parameter rather than adding another refuse directive.)
+
+

+Daemon security fixes in 3.0.0 (with patches for 2.6.9)
+First published on November 28th, 2007;

+Updated on December 16th, 2007;

+Item 3 added on February 15th, 2008
+
+Three security advisories affect people who run a writable rsync
+daemon:  The first affects only those with "use chroot = no" (which is not a
+very safe combination in general), the second affects a daemon that has
+daemon-excluded files that are being hidden in a module's hierarchy, and
+the third affects only those with "use chroot = yes".
+Included are simple config-change suggestions that should help you to
+avoid the security issues and patches that make things safer.
+These advisories affect all rsync versions.
+
+
1. Daemon advisory for "use chroot = no"
+
+If you are running a writable rsync daemon with "use chroot = no", there
+is at least one way for someone to trick rsync into creating a symlink
+that points outside of the module's hierarchy.
+
+
This means that if you are allowing access from users who you don't
+trust, that you should either figure out a way to turn on "use chroot",
+or configure the daemon to refuse the "links" option (see "refuse
+options" in the rsyncd.conf manpage) which will disable the ability of
+the rsync module to receive symlinks.  After doing so, you should also
+check that any existing symlinks in the daemon hierarchy are safe.
+
+
Starting with the 3.0.0-pre6 release, there is a new daemon parameter
+available: "munge symlinks".  This allows an rsync daemon to accept
+symlinks and return them intact (with even a leading slash still there,
+which is new for a non-chroot daemon), but will not allow the symlinks
+to be used while they are in the daemon's hierarchy.
+
+
For those running
+2.6.9, there is
+a
+patch for 2.6.9 to implement this parameter.
+
+
Any admin applying that patch should read the "munge symlinks" section
+of the modified rsyncd.conf manpage for more information.  You can also
+read about this parameter in the
+rsyncd.conf
+manpage from a 3.x version.
+
+
2. Daemon advisory for daemon excludes
+
+If you are running a writable rsync daemon that is using one of the
+"exclude", "exclude from", or "filter" parameters in the rsyncd.conf file
+to hide data from your users, you should be aware that there are tricks
+that a user can play with symlinks and/or certain options that can allow
+a user that knows the name of a hidden file to access it or overwrite it
+(if file permissions allow that).
+
+
You can avoid the symlink problem using the suggestions in the advisory
+above.
+
+
When a daemon has "use chroot = no" set , there was some buggy
+exclude-checking for these options: --compare-dest,
+--link-dest, --copy-dest, --partial-dir,
+--backup-dir, --temp-dir, and
+--files-from.  These are fixed in the 3.0.0pre7 release.  For
+those running 2.6.9, there is a patch for
+2.6.9 to fix these checks.
+
+
Some of the above options can still cause problems if an excluded
+sub-directory or filename is inside the option's directory hierarchy and the
+names of a transferred file clashes with it.  The affected options are the
+various --*-dest options (of which only --link-dest
+is particularly worrisome),
+--backup-dir, and --partial-dir.
+
+
You can avoid these sub-path problems by putting the following "refuse
+options" setting into your rsyncd.conf file:
+
+
refuse options = link-dest backup-dir partial-dir
+
+Those who aren't using an rsync with the latest exclude fixes may want to add
+some of the other affected options as well.
+
+
3. Daemon advisory for "use chroot = yes"
+
+If you are running a writable rsync daemon with "use chroot = yes", you
+should take care that users cannot upload their own library files and attempt
+to load them.
+
+
Beginning with rsync 3.0.0pre10, you can specify an inside-chroot path that
+makes the top of the transfer a subdirectory inside the chroot area, and that
+automatically makes library loading occur outside the transfer area (assuming
+you didn't pick an unwise subdirectory name for the transfer area and you
+don't have symlinks that point outside the transfer area).
+
+
If that solution is not good for you, the easiest way to protect your daemon
+is to create some appropriate directories in the top of your module's path
+hierarchy, such as "/etc", "/lib", and "/usr" (and any other top-level dirs
+that might be in the load path), chown those directories to some other user
+than the one that the module runs as (so that rsync will not be able to write
+files there, assuming that it is not run as root), and then hide the dirs using
+an exclude directive (either add a new one or extend your existing one):
+
+
exclude = /etc /lib /usr
+
+Doing all that will assure you that no user will be able to use rsync to
+upload a library that can be potentially loaded while rsync is attempting to
+perform an action, such as translating a username.  You can feel free to put
+trusted libraries that you want rsync to access in the protected hierarchies,
+as desired.
+
+
Also available in rsync 3.0.0pre10 is a new daemon parameter that allows you
+to avoid the accessing of user/group-name translation libraries by a chrooted
+rsync:  the "numeric ids" daemon parameter lets you turn on a forced
+numeric-only mode.  The default for a chroot module is to enable this
+parameter, while the default for a non-chroot module is to disable it.
+
+
For those running 2.6.9, there is a patch for
+2.6.9 to add the "numeric ids" daemon config parameter.  (The patch will
+only apply cleanly if you've already applied the munge-symlinks diff mentioned
+above.)
+
+

+Xattr security fix in 2.6.8
+April 22th, 2006
+
+If you're using a version of rsync prior to 2.6.8 that was patched to
+include extended attribute (xattr) support, you should upgrade to 2.6.8 or
+later to avoid a potential buffer overflow problem.
+
+

+Zlib security fix in 2.6.6
+July 28th, 2005
+
+If you're using a version of rsync prior to 2.6.6, there is a potential
+null-pointer security bug in the zlib code.  You can avoid its affect in an
+rsync daemon situation by configuring rsync to refuse the "compress" option.
+
+

+Daemon path-sanitizing fix in 2.6.3
+August 12th, 2004
+
+There is a path-sanitizing bug that affects daemon-mode in
+rsync versions prior to 2.6.3, but only if "use chroot" is disabled.  It
+does not affect the normal send/receive filenames that specify what
+files should be transferred (this is because these names happen to get
+sanitized twice, and thus the second call removes any lingering leading
+slash(es) that the first call left behind).  It does affect certain
+option paths that cause auxiliary files to be read or written.
+
+
One potential fix that doesn't require recompiling rsync is to set
+"use chroot = true" for all the modules in the rsyncd.conf file.
+
+

+Daemon security fix in 2.6.1
+April 26th, 2004
+
+There is a security problem in all versions prior to 2.6.1 that affects only
+people running a read/write daemon with "use chroot" disabled.  If the user privs
+of a module in the daemon config is anything above "nobody", you are at risk
+of someone crafting an attack that could write a file outside of the module's
+"path" setting (where all its files should be stored).  Please either enable
+chroot or upgrade to 2.6.1.  People not running a daemon, running a read-only
+daemon, or running a chrooted daemon are totally unaffected.
+
+

+Memory overflow fix in 2.5.7
+December 4th, 2003
+
+Rsync versions prior to 2.5.7 contain a heap overflow vulnerability that
+could be used to remotely run arbitrary code, but this only affects the use of
+rsync as an "rsync daemon" (where rsync handles incoming socket connections,
+typically on port 873).
+
+
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
+
 
diff --git a/rsync-web/susan.txt b/rsync-web/susan.txt
new file mode 100644
index 00000000..2d8a67e3
--- /dev/null
+++ b/rsync-web/susan.txt
@@ -0,0 +1,31 @@
+I use rsync to backup my wifes home directory across a modem link each
+night. The cron job looks like this
+
+    #!/bin/sh
+    cd ~susan
+    {
+    echo
+    date
+    dest=~/backup/`date +%A`
+    mkdir $dest.new
+    find . -xdev -type f \( -mtime 0 -or -mtime 1 \) -exec cp -aPv "{}"
+    $dest.new \;
+    cnt=`find $dest.new -type f | wc -l`
+    if [ $cnt -gt 0 ]; then
+      rm -rf $dest
+      mv $dest.new $dest
+    fi
+    rm -rf $dest.new
+    rsync -Cavze ssh . samba:backup
+    } >> ~/backup/backup.log 2>&1
+
+
+note that most of this script isn't anything to do with rsync, it just
+creates a daily backup of Susans work in a ~susan/backup/ directory so
+she can retrieve any version from the last week. The last line does
+the rsync of her directory across the modem link to the host
+samba. Note that I am using the -C option which allows me to add
+entries to .cvsignore for stuff that doesn't need to be backed up.
+
+
+
diff --git a/rsync-web/tech_report/footnode.html b/rsync-web/tech_report/footnode.html
new file mode 100644
index 00000000..0c66b881
--- /dev/null
+++ b/rsync-web/tech_report/footnode.html
@@ -0,0 +1,134 @@
+
+
+
+
+Footnotes
+
+
+
+
+
+
+
+
+
+
+
+

+... bytes¹
+
We have found that
+  values of S between 500 and 1000 are quite good for most purposes
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+
+
... size.²
+
All the tests in this section were
+  carried out using rsync version 0.5
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+
+
... files.³
+
The wall
+  clock time was approximately 2 minutes per run on a 50 MHz SPARC 10
+  running SunOS, using rsh over loopback for communication.  GNU diff
+  took about 4 minutes.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+.
+
+

+Andrew Tridgell
+
1998-11-09
+
+
+
diff --git a/rsync-web/tech_report/images.aux b/rsync-web/tech_report/images.aux
new file mode 100644
index 00000000..f23e5468
--- /dev/null
+++ b/rsync-web/tech_report/images.aux
@@ -0,0 +1 @@
+\relax 
diff --git a/rsync-web/tech_report/images.log b/rsync-web/tech_report/images.log
new file mode 100644
index 00000000..4344b35f
--- /dev/null
+++ b/rsync-web/tech_report/images.log
@@ -0,0 +1,106 @@
+This is TeX, Version 3.14159 (C version 6.1) (format=latex 97.10.16)  9 NOV 1998 20:10
+**./images.tex
+(images.tex
+LaTeX2e <1996/12/01> patch level 1
+Babel  and hyphenation patterns for american, german, loaded.
+
+(/usr/lib/texmf/texmf/tex/latex/base/article.cls
+Document Class: article 1996/10/31 v1.3u Standard LaTeX document class
+(/usr/lib/texmf/texmf/tex/latex/base/size10.clo
+File: size10.clo 1996/10/31 v1.3u Standard LaTeX file (size option)
+)
+\c@part=\count79
+\c@section=\count80
+\c@subsection=\count81
+\c@subsubsection=\count82
+\c@paragraph=\count83
+\c@subparagraph=\count84
+\c@figure=\count85
+\c@table=\count86
+\abovecaptionskip=\skip41
+\belowcaptionskip=\skip42
+\bibindent=\dimen102
+) (/usr/lib/texmf/texmf/tex/latex/graphics/color.sty
+Package: color 1997/01/07 v1.0d Standard LaTeX Color (DPC)
+(/usr/lib/texmf/texmf/tex/latex/config/color.cfg)
+Package color Info: Driver file: dvips.def on input line 128.
+(/usr/lib/texmf/texmf/tex/latex/graphics/dvips.def
+File: dvips.def 1996/12/12 v3.0d Driver-dependant file (DPC,SPQR)
+) (/usr/lib/texmf/texmf/tex/latex/graphics/dvipsnam.def
+File: dvipsnam.def 1996/12/12 v3.0d Driver-dependant file (DPC,SPQR)
+))
+\sizebox=\box26
+\lthtmlwrite=\write3
+No file images.aux.
+LaTeX Font Info:    Checking defaults for OML/cmm/m/it on input line 74.
+LaTeX Font Info:    ... okay on input line 74.
+LaTeX Font Info:    Checking defaults for T1/cmr/m/n on input line 74.
+LaTeX Font Info:    ... okay on input line 74.
+LaTeX Font Info:    Checking defaults for OT1/cmr/m/n on input line 74.
+LaTeX Font Info:    ... okay on input line 74.
+LaTeX Font Info:    Checking defaults for OMS/cmsy/m/n on input line 74.
+LaTeX Font Info:    ... okay on input line 74.
+LaTeX Font Info:    Checking defaults for OMX/cmex/m/n on input line 74.
+LaTeX Font Info:    ... okay on input line 74.
+LaTeX Font Info:    Checking defaults for U/cmr/m/n on input line 74.
+LaTeX Font Info:    ... okay on input line 74.
+latex2htmlLength hsize=349.0pt
+latex2htmlLength vsize=682.0pt
+latex2htmlLength hoffset=0.0pt
+latex2htmlLength voffset=0.0pt
+latex2htmlLength topmargin=0.0pt
+latex2htmlLength topskip=0.00003pt
+latex2htmlLength headheight=0.0pt
+latex2htmlLength headsep=0.0pt
+latex2htmlLength parskip=0.0pt plus 1.0pt
+latex2htmlLength oddsidemargin=53.0pt
+latex2htmlLength evensidemargin=53.0pt
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <7> on input line 94.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <5> on input line 94.
+l2hSize :tex2html_wrap_inline88:6.45831pt::0.0pt::6.43404pt.
+[1
+
+
+]
+l2hSize :tex2html_wrap_inline90:7.44444pt::7.44444pt::6.18402pt.
+[2
+
+
+]
+l2hSize :displaymath158:32.38896pt::0.0pt::349.0pt.
+[3
+
+
+]
+l2hSize :displaymath160:32.38896pt::0.0pt::349.0pt.
+[4
+
+
+]
+l2hSize :tex2html_wrap_inline166:7.33331pt::7.33331pt::39.55894pt.
+[5
+
+
+]
+l2hSize :displaymath170:14.5pt::0.0pt::349.0pt.
+[6
+
+
+]
+l2hSize :displaymath172:14.5pt::0.0pt::349.0pt.
+[7
+
+
+] (images.aux) ) 
+Here is how much of TeX's memory you used:
+ 518 strings out of 10906
+ 6196 string characters out of 72186
+ 46914 words of memory out of 262141
+ 3454 multiletter control sequences out of 9500
+ 3640 words of font info for 14 fonts, out of 150000 for 255
+ 14 hyphenation exceptions out of 607
+ 23i,5n,19p,182b,215s stack positions out of 300i,40n,60p,3000b,4000s
+
+Output written on images.dvi (7 pages, 2296 bytes).
diff --git a/rsync-web/tech_report/images.pl b/rsync-web/tech_report/images.pl
new file mode 100644
index 00000000..6fb022fb
--- /dev/null
+++ b/rsync-web/tech_report/images.pl
@@ -0,0 +1,48 @@
+# LaTeX2HTML 98.1p1 release (March 2nd, 1998)
+# Associate images original text with physical files.
+
+
+$key = q/{inline}alpha{inline}MSF=1.6;AAT;/;
+$cached_env_img{$key} = q||; 
+
+$key = q/{displaymath}a(k+1,l+1)=(a(k,l)-X_k+X_l+1)bmodM{displaymath}MSF=1.6;AAT;/;
+$cached_env_img{$key} = q||; 
+
+$key = q/{displaymath}a(k,l)=(sum_i=k^lX_i)bmodM{displaymath}MSF=1.6;AAT;/;
+$cached_env_img{$key} = q||; 
+
+$key = q/{displaymath}b(k,l)=(sum_i=k^l(l-i+1)X_i)bmodM{displaymath}MSF=1.6;AAT;/;
+$cached_env_img{$key} = q||; 
+
+$key = q/{inline}X_kldotsX_l{inline}MSF=1.6;AAT;/;
+$cached_env_img{$key} = q||; 
+
+$key = q/{displaymath}b(k+1,l+1)=(b(k,l)-(l-k+1)X_k+a(k+1,l+1))bmodM{displaymath}MSF=1.6;AAT;/;
+$cached_env_img{$key} = q||; 
+
+$key = q/{inline}beta{inline}MSF=1.6;AAT;/;
+$cached_env_img{$key} = q||; 
+
+1;
+
diff --git a/rsync-web/tech_report/images.tex b/rsync-web/tech_report/images.tex
new file mode 100644
index 00000000..61a3d9e5
--- /dev/null
+++ b/rsync-web/tech_report/images.tex
@@ -0,0 +1,140 @@
+\batchmode
+\documentclass[a4paper]{article}
+\makeatletter
+\usepackage[dvips]{color}
+\pagecolor[gray]{.7}
+
+
+\makeatletter
+\count@=\the\catcode`\_ \catcode`\_=8 
+\newenvironment{tex2html_wrap}{}{} \catcode`\_=\count@
+\makeatother
+\let\mathon=$
+\let\mathoff=$
+\ifx\AtBeginDocument\undefined \newcommand{\AtBeginDocument}[1]{}\fi
+\newbox\sizebox
+\setlength{\hoffset}{0pt}\setlength{\voffset}{0pt}
+\addtolength{\textheight}{\footskip}\setlength{\footskip}{0pt}
+\addtolength{\textheight}{\topmargin}\setlength{\topmargin}{0pt}
+\addtolength{\textheight}{\headheight}\setlength{\headheight}{0pt}
+\addtolength{\textheight}{\headsep}\setlength{\headsep}{0pt}
+\setlength{\textwidth}{349pt}
+\newwrite\lthtmlwrite
+\makeatletter
+\let\realnormalsize=\normalsize
+\global\topskip=2sp
+\def\preveqno{}\let\real@float=\@float \let\realend@float=\end@float
+\def\@float{\let\@savefreelist\@freelist\real@float}
+\def\end@float{\realend@float\global\let\@freelist\@savefreelist}
+\let\real@dbflt=\@dbflt \let\end@dblfloat=\end@float
+\let\@largefloatcheck=\relax
+\def\@dbflt{\let\@savefreelist\@freelist\real@dbflt}
+\def\adjustnormalsize{\def\normalsize{\mathsurround=0pt \realnormalsize
+ \parindent=0pt\abovedisplayskip=0pt\belowdisplayskip=0pt}\normalsize}%
+\def\lthtmltypeout#1{{\let\protect\string\immediate\write\lthtmlwrite{#1}}}%
+\newcommand\lthtmlhboxmathA{\adjustnormalsize\setbox\sizebox=\hbox\bgroup}%
+\newcommand\lthtmlvboxmathA{\adjustnormalsize\setbox\sizebox=\vbox\bgroup%
+ \let\ifinner=\iffalse }%
+\newcommand\lthtmlboxmathZ{\@next\next\@currlist{}{\def\next{\voidb@x}}%
+ \expandafter\box\next\egroup}%
+\newcommand\lthtmlmathtype[1]{\def\lthtmlmathenv{#1}}%
+\newcommand\lthtmllogmath{\lthtmltypeout{l2hSize %
+:\lthtmlmathenv:\the\ht\sizebox::\the\dp\sizebox::\the\wd\sizebox.\preveqno}}%
+\newcommand\lthtmlfigureA[1]{\let\@savefreelist\@freelist
+       \lthtmlmathtype{#1}\lthtmlvboxmathA}%
+\newcommand\lthtmlfigureZ{\lthtmlboxmathZ\lthtmllogmath\copy\sizebox
+       \global\let\@freelist\@savefreelist}%
+\newcommand\lthtmldisplayA[1]{\lthtmlmathtype{#1}\lthtmlvboxmathA}%
+\newcommand\lthtmldisplayB[1]{\edef\preveqno{(\theequation)}%
+  \lthtmldisplayA{#1}\let\@eqnnum\relax}%
+\newcommand\lthtmldisplayZ{\lthtmlboxmathZ\lthtmllogmath\lthtmlsetmath}%
+\newcommand\lthtmlinlinemathA[1]{\lthtmlmathtype{#1}\lthtmlhboxmathA  \vrule height1.5ex width0pt }%
+\newcommand\lthtmlinlineA[1]{\lthtmlmathtype{#1}\lthtmlhboxmathA}%
+\newcommand\lthtmlinlineZ{\egroup\expandafter\ifdim\dp\sizebox>0pt %
+  \expandafter\centerinlinemath\fi\lthtmllogmath\lthtmlsetinline}
+\newcommand\lthtmlinlinemathZ{\egroup\expandafter\ifdim\dp\sizebox>0pt %
+  \expandafter\centerinlinemath\fi\lthtmllogmath\lthtmlsetmath}
+\def\lthtmlsetinline{\hbox{\vrule width.1em\vtop{\vbox{%
+  \kern.1em\copy\sizebox}\ifdim\dp\sizebox>0pt\kern.1em\else\kern.3pt\fi
+  \ifdim\hsize>\wd\sizebox \hrule depth1pt\fi}}}
+\def\lthtmlsetmath{\hbox{\vrule width.1em\vtop{\vbox{%
+  \kern.1em\kern0.8 pt\hbox{\hglue.17em\copy\sizebox\hglue0.8 pt}}\kern.3pt%
+  \ifdim\dp\sizebox>0pt\kern.1em\fi \kern0.8 pt%
+  \ifdim\hsize>\wd\sizebox \hrule depth1pt\fi}}}
+\def\centerinlinemath{%\dimen1=\ht\sizebox
+  \dimen1=\ifdim\ht\sizebox<\dp\sizebox \dp\sizebox\else\ht\sizebox\fi
+  \advance\dimen1by.5pt \vrule width0pt height\dimen1 depth\dimen1 
+ \dp\sizebox=\dimen1\ht\sizebox=\dimen1\relax}
+
+\def\lthtmlcheckvsize{\ifdim\ht\sizebox<\vsize\expandafter\vfill
+  \else\expandafter\vss\fi}%
+\makeatletter \tracingstats = 1 
+
+
+\begin{document}
+\pagestyle{empty}\thispagestyle{empty}%
+\lthtmltypeout{latex2htmlLength hsize=\the\hsize}%
+\lthtmltypeout{latex2htmlLength vsize=\the\vsize}%
+\lthtmltypeout{latex2htmlLength hoffset=\the\hoffset}%
+\lthtmltypeout{latex2htmlLength voffset=\the\voffset}%
+\lthtmltypeout{latex2htmlLength topmargin=\the\topmargin}%
+\lthtmltypeout{latex2htmlLength topskip=\the\topskip}%
+\lthtmltypeout{latex2htmlLength headheight=\the\headheight}%
+\lthtmltypeout{latex2htmlLength headsep=\the\headsep}%
+\lthtmltypeout{latex2htmlLength parskip=\the\parskip}%
+\lthtmltypeout{latex2htmlLength oddsidemargin=\the\oddsidemargin}%
+\makeatletter
+\if@twoside\lthtmltypeout{latex2htmlLength evensidemargin=\the\evensidemargin}%
+\else\lthtmltypeout{latex2htmlLength evensidemargin=\the\oddsidemargin}\fi%
+\makeatother
+\stepcounter{section}
+\stepcounter{section}
+{\newpage\clearpage
+\lthtmlinlinemathA{tex2html_wrap_inline88}%
+$\alpha$%
+\lthtmlinlinemathZ
+\hfill\lthtmlcheckvsize\clearpage}
+
+{\newpage\clearpage
+\lthtmlinlinemathA{tex2html_wrap_inline90}%
+$\beta$%
+\lthtmlinlinemathZ
+\hfill\lthtmlcheckvsize\clearpage}
+
+\stepcounter{section}
+{\newpage\clearpage
+\lthtmldisplayA{displaymath158}%
+\begin{displaymath}a(k,l) = (\sum_{i=k}^l X_i) \bmod M \end{displaymath}%
+\lthtmldisplayZ
+\hfill\lthtmlcheckvsize\clearpage}
+
+{\newpage\clearpage
+\lthtmldisplayA{displaymath160}%
+\begin{displaymath}b(k,l) = (\sum_{i=k}^l (l-i+1)X_i) \bmod M \end{displaymath}%
+\lthtmldisplayZ
+\hfill\lthtmlcheckvsize\clearpage}
+
+{\newpage\clearpage
+\lthtmlinlinemathA{tex2html_wrap_inline166}%
+$X_k \ldots X_l$%
+\lthtmlinlinemathZ
+\hfill\lthtmlcheckvsize\clearpage}
+
+{\newpage\clearpage
+\lthtmldisplayA{displaymath170}%
+\begin{displaymath}a(k+1,l+1) = (a(k,l) - X_k + X_{l+1}) \bmod M \end{displaymath}%
+\lthtmldisplayZ
+\hfill\lthtmlcheckvsize\clearpage}
+
+{\newpage\clearpage
+\lthtmldisplayA{displaymath172}%
+\begin{displaymath}b(k+1,l+1) = (b(k,l) - (l-k+1) X_k + a(k+1,l+1)) \bmod M \end{displaymath}%
+\lthtmldisplayZ
+\hfill\lthtmlcheckvsize\clearpage}
+
+\stepcounter{section}
+\stepcounter{section}
+\stepcounter{section}
+\stepcounter{section}
+
+\end{document}
diff --git a/rsync-web/tech_report/img1.gif b/rsync-web/tech_report/img1.gif
new file mode 100644
index 00000000..d475550e
Binary files /dev/null and b/rsync-web/tech_report/img1.gif differ
diff --git a/rsync-web/tech_report/img2.gif b/rsync-web/tech_report/img2.gif
new file mode 100644
index 00000000..fdc79866
Binary files /dev/null and b/rsync-web/tech_report/img2.gif differ
diff --git a/rsync-web/tech_report/img3.gif b/rsync-web/tech_report/img3.gif
new file mode 100644
index 00000000..3479fed6
Binary files /dev/null and b/rsync-web/tech_report/img3.gif differ
diff --git a/rsync-web/tech_report/img4.gif b/rsync-web/tech_report/img4.gif
new file mode 100644
index 00000000..b7ae4971
Binary files /dev/null and b/rsync-web/tech_report/img4.gif differ
diff --git a/rsync-web/tech_report/img5.gif b/rsync-web/tech_report/img5.gif
new file mode 100644
index 00000000..07128ec5
Binary files /dev/null and b/rsync-web/tech_report/img5.gif differ
diff --git a/rsync-web/tech_report/img6.gif b/rsync-web/tech_report/img6.gif
new file mode 100644
index 00000000..3ab1bf24
Binary files /dev/null and b/rsync-web/tech_report/img6.gif differ
diff --git a/rsync-web/tech_report/img7.gif b/rsync-web/tech_report/img7.gif
new file mode 100644
index 00000000..4a104e1a
Binary files /dev/null and b/rsync-web/tech_report/img7.gif differ
diff --git a/rsync-web/tech_report/index.html b/rsync-web/tech_report/index.html
new file mode 100644
index 00000000..77bf9fc2
--- /dev/null
+++ b/rsync-web/tech_report/index.html
@@ -0,0 +1,94 @@
+
+
+
+
+The rsync algorithm
+
+
+
+
+
+
+
+
+
+
+
+ 
+ 
+   
+

+ Next: The problem
+

+

+
+
+
+
+

+
+

+
The rsync algorithm
+Andrew Tridgell         Paul Mackerras
+

+Department of Computer Science 

+Australian National University 

+Canberra, ACT 0200, Australia
+
+
+
+
+
Abstract:
+
+This report presents an algorithm for updating a file on one machine
+  to be identical to a file on another machine.  We assume that the
+  two machines are connected by a low-bandwidth high-latency
+  bi-directional communications link.  The algorithm identifies parts
+  of the source file which are identical to some part of the
+  destination file, and only sends those parts which cannot be matched
+  in this way.  Effectively, the algorithm computes a set of
+  differences without having both files on the same machine.  The
+  algorithm works best when the files are similar, but will also
+  function correctly and reasonably efficiently when the files are
+  quite different.
+
+
+

+

+
+ 
+
+The problem
+
The rsync algorithm
+
Rolling checksum
+
Checksum searching
+
Pipelining
+
Results
+
Availability
+
About this document ... 
+
+
+

+
+Andrew Tridgell
+
1998-11-09
+
+
+
diff --git a/rsync-web/tech_report/labels.pl b/rsync-web/tech_report/labels.pl
new file mode 100644
index 00000000..eded2434
--- /dev/null
+++ b/rsync-web/tech_report/labels.pl
@@ -0,0 +1,6 @@
+# LaTeX2HTML 98.1p1 release (March 2nd, 1998)
+# Associate labels original text with physical files.
+
+
+1;
+
diff --git a/rsync-web/tech_report/next.gif b/rsync-web/tech_report/next.gif
new file mode 100644
index 00000000..7a2dbe95
Binary files /dev/null and b/rsync-web/tech_report/next.gif differ
diff --git a/rsync-web/tech_report/node1.html b/rsync-web/tech_report/node1.html
new file mode 100644
index 00000000..83c726a4
--- /dev/null
+++ b/rsync-web/tech_report/node1.html
@@ -0,0 +1,119 @@
+
+
+
+
+The problem
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+
+ 
+
+   
+

+ Next: The rsync algorithm
+ Up: The rsync algorithm
+ Previous: The rsync algorithm
+

+

+
+
+
+The problem
+
+
+
+Imagine you have two files, A and B, and you wish to update B to be
+the same as A. The obvious method is to copy A onto B.
+
+

+Now imagine that the two files are on machines connected by a slow
+communications link, for example a dial up IP link.  If A is large,
+copying A onto B will be slow.  To make it faster you could
+compress A before sending it, but that will usually only gain a
+factor of 2 to 4.
+
+

+Now assume that A and B are quite similar, perhaps both derived
+from the same original file. To really speed things up you would need
+to take advantage of this similarity. A common method is to send just
+the differences between A and B down the link and then use this
+list of differences to reconstruct the file.
+
+

+The problem is that the normal methods for creating a set of
+differences between two files rely on being able to read both files.
+Thus they require that both files are available beforehand at one end
+of the link.  If they are not both available on the same machine,
+these algorithms cannot be used (once you had copied the file over,
+you wouldn't need the differences).  This is the problem that rsync
+addresses.
+
+

+The rsync algorithm efficiently computes which parts of a source file
+match some part of an existing destination file.  These parts need not
+be sent across the link; all that is needed is a reference to the part
+of the destination file.  Only parts of the source file which are not
+matched in this way need to be sent verbatim.  The receiver can then
+construct a copy of the source file using the references to parts of
+the existing destination file and the verbatim material.
+
+

+Trivially, the data sent to the receiver can be compressed using any
+of a range of common compression algorithms, for further speed
+improvements.
+
+

+

+
+
+ 
+
+ 
+
+   
+

+ Next: The rsync algorithm
+ Up: The rsync algorithm
+ Previous: The rsync algorithm
+
+
+Andrew Tridgell
+
1998-11-09
+
+
+
diff --git a/rsync-web/tech_report/node2.html b/rsync-web/tech_report/node2.html
new file mode 100644
index 00000000..c1f299d4
--- /dev/null
+++ b/rsync-web/tech_report/node2.html
@@ -0,0 +1,183 @@
+
+
+
+
+The rsync algorithm
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+
+ 
+
+   
+

+ Next: Rolling checksum
+ Up: The rsync algorithm
+ Previous: The problem
+

+

+
+
+
+The rsync algorithm
+
+
+
+Suppose we have two general purpose computers 
+and .
+Computer 
+has access to a file A and 
+has access to
+file B, where A and B are ``similar''.  There is a slow
+communications link between 
+and .
+
+

+The rsync algorithm consists of the following steps:
+
+

+

+1.
+

+splits the file B into a series of non-overlapping
+fixed-sized blocks of size S bytes¹.
+  The last block may be shorter than S bytes.
+
+
+
2.
+
For each of these blocks 
+calculates two checksums:
+  a weak ``rolling'' 32-bit checksum (described below) and a strong
+  128-bit MD4 checksum.
+
+
+
3.
+

+sends these checksums to .
+  
+
4.
+

+searches through A to find all blocks of length S  bytes (at any offset, not just multiples of S) that have the same
+  weak and strong checksum as one of the blocks of B. This can be
+  done in a single pass very quickly using a special property of the
+  rolling checksum described below.
+  
+
5.
+

+sends 
+a sequence of instructions for
+  constructing a copy of A.  Each instruction is either a reference
+  to a block of B, or literal data.  Literal data is sent only for
+  those sections of A which did not match any of the blocks of B.
+
+
+The end result is that 
+gets a copy of A, but only the pieces
+of A that are not found in B (plus a small amount of data for
+checksums and block indexes) are sent over the link. The algorithm
+also only requires one round trip, which minimises the impact of the
+link latency.
+
+

+The most important details of the algorithm are the rolling checksum
+and the associated multi-alternate search mechanism which allows the
+all-offsets checksum search to proceed very quickly. These will be
+discussed in greater detail below.
+
+

+

+
+
+ 
+
+ 
+
+   
+

+ Next: Rolling checksum
+ Up: The rsync algorithm
+ Previous: The problem
+
+
+Andrew Tridgell
+
1998-11-09
+
+
+
diff --git a/rsync-web/tech_report/node3.html b/rsync-web/tech_report/node3.html
new file mode 100644
index 00000000..2d36abdd
--- /dev/null
+++ b/rsync-web/tech_report/node3.html
@@ -0,0 +1,187 @@
+
+
+
+
+Rolling checksum
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+
+ 
+
+   
+

+ Next: Checksum searching
+ Up: The rsync algorithm
+ Previous: The rsync algorithm
+

+

+
+
+
+Rolling checksum
+
+
+
+The weak rolling checksum used in the rsync algorithm needs to have
+the property that it is very cheap to calculate the checksum of a
+buffer 
+
+X₂ .. X_n+1 given the checksum of buffer 
+
+X₁ .. X_n and
+the values of the bytes X₁ and X_n+1.
+
+

+The weak checksum algorithm we used in our implementation was inspired
+by Mark Adler's adler-32 checksum.  Our checksum is defined by
+

+
+
+
+
+
+
+

+
+

+
+
+
+
+
+
+

+
+

+
+
+
+
+s(k,l) = a(k,l) + 2¹⁶ b(k,l)
+
+

+
+
+where s(k,l) is the rolling checksum of the bytes 
+
+.
+For simplicity and speed, we use 
+
+M = 2¹⁶.  
+
+

+The important property of this checksum is that successive values can
+be computed very efficiently using the recurrence relations
+
+

+

+
+
+
+
+
+
+

+
+

+
+
+
+
+
+
+

+
+
+Thus the checksum can be calculated for blocks of length S at all
+possible offsets within a file in a ``rolling'' fashion, with very
+little computation at each point.
+
+

+Despite its simplicity, this checksum was found to be quite adequate as
+a first level check for a match of two file blocks.  We have found in
+practice that the probability of this checksum matching when the
+blocks are not equal is quite low.  This is important because the much
+more expensive strong checksum must be calculated for each block where
+the weak checksum matches.
+
+

+

+
+
+ 
+
+ 
+
+   
+

+ Next: Checksum searching
+ Up: The rsync algorithm
+ Previous: The rsync algorithm
+
+
+Andrew Tridgell
+
1998-11-09
+
+
+
diff --git a/rsync-web/tech_report/node4.html b/rsync-web/tech_report/node4.html
new file mode 100644
index 00000000..de8a2723
--- /dev/null
+++ b/rsync-web/tech_report/node4.html
@@ -0,0 +1,145 @@
+
+
+
+
+Checksum searching
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+
+ 
+
+   
+

+ Next: Pipelining
+ Up: The rsync algorithm
+ Previous: Rolling checksum
+

+

+
+
+
+Checksum searching
+
+
+
+Once 
+has received the list of checksums of the blocks of B,
+it must search A for any blocks at any offset that match the
+checksum of some block of B.  The basic strategy is to compute the
+32-bit rolling checksum for a block of length S starting at each
+byte of A in turn, and for each checksum, search the list for a
+match.  To do this our implementation uses a
+simple 3 level searching scheme.
+
+

+The first level uses a 16-bit hash of the 32-bit rolling checksum and
+a 2¹⁶ entry hash table.  The list of checksum values (i.e., the
+checksums from the blocks of B) is sorted according to the 16-bit
+hash of the 32-bit rolling checksum.  Each entry in the hash table
+points to the first element of the list for that hash value, or
+contains a null value if no element of the list has that hash value.
+
+

+At each offset in the file the 32-bit rolling checksum and its 16-bit
+hash are calculated.  If the hash table entry for that hash value is
+not a null value, the second level check is invoked.
+
+

+The second level check involves scanning the sorted checksum list
+starting with the entry pointed to by the hash table entry, looking
+for an entry whose 32-bit rolling checksum matches the current value.
+The scan terminates when it reaches an entry whose 16-bit hash
+differs.  If this search finds a match, the third level check is
+invoked.
+
+

+The third level check involves calculating the strong checksum for the
+current offset in the file and comparing it with the strong checksum
+value in the current list entry.  If the two strong checksums match,
+we assume that we have found a block of A which matches a block of
+B.  In fact the blocks could be different, but the probability of
+this is microscopic, and in practice this is a reasonable assumption.
+
+

+When a match is found, 
+sends 
+the data in A between
+the current file offset and the end of the previous match, followed by
+the index of the block in B that matched.  This data is sent
+immediately a match is found, which allows us to overlap the
+communication with further computation.
+
+

+If no match is found at a given offset in the file, the rolling
+checksum is updated to the next offset and the search proceeds.  If a
+match is found, the search is restarted at the end of the matched
+block.  This strategy saves a considerable amount of computation for
+the common case where the two files are nearly identical.  In
+addition, it would be a simple matter to encode the block indexes as
+runs, for the common case where a portion of A matches a series of
+blocks of B in order.
+
+

+

+
+
+ 
+
+ 
+
+   
+

+ Next: Pipelining
+ Up: The rsync algorithm
+ Previous: Rolling checksum
+
+
+Andrew Tridgell
+
1998-11-09
+
+
+
diff --git a/rsync-web/tech_report/node5.html b/rsync-web/tech_report/node5.html
new file mode 100644
index 00000000..5392a93a
--- /dev/null
+++ b/rsync-web/tech_report/node5.html
@@ -0,0 +1,85 @@
+
+
+
+
+Pipelining
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+
+ 
+
+   
+

+ Next: Results
+ Up: The rsync algorithm
+ Previous: Checksum searching
+

+

+
+
+
+Pipelining
+
+
+
+The above sections describe the process for constructing a copy of one
+file on a remote system.  If we have a several files to copy, we can
+gain a considerable latency advantage by pipelining the process.
+
+

+This involves 
+initiating two independent processes. One of the
+processes generates and sends the checksums to 
+while the
+other receives the difference information from 
+and
+reconstructs the files. 
+
+

+If the communications link is buffered then these two processes can
+proceed independently and the link should be kept fully utilised in
+both directions for most of the time. 
+
+

+

+
+Andrew Tridgell
+
1998-11-09
+
+
+
diff --git a/rsync-web/tech_report/node6.html b/rsync-web/tech_report/node6.html
new file mode 100644
index 00000000..baae473e
--- /dev/null
+++ b/rsync-web/tech_report/node6.html
@@ -0,0 +1,299 @@
+
+
+
+
+Results
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+
+ 
+
+   
+

+ Next: Availability
+ Up: The rsync algorithm
+ Previous: Pipelining
+

+

+
+
+
+Results
+
+
+
+To test the algorithm, tar files were created of the Linux kernel
+sources for two versions of the kernel. The two kernel versions were
+1.99.10 and 2.0.0. These tar files are approximately 24MB in size and
+are separated by 5 released patch levels.
+
+

+Out of the 2441 files in the 1.99.10 release, 291 files had changed in
+the 2.0.0 release, 19 files had been removed and 25 files had been
+added.
+
+

+A ``diff'' of the two tar files using the standard GNU diff utility
+produced over 32 thousand lines of output totalling 2.1 MB.
+
+

+The following table shows the results for rsync between the two files
+with a varying block size.²
+
+

+

+

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ block  matches  tag  false  data  written  read
 size    hits  alarms      

+300 64247 3817434 948 5312200 5629158 1632284
500 46989 620013 64 1091900 1283906 979384
700 33255 571970 22 1307800 1444346 699564
900 25686 525058 24 1469500 1575438 544124
1100 20848 496844 21 1654500 1740838 445204
+

+

+
+

+In each case, the CPU time taken was less than the
+time it takes to run ``diff'' on the two files.³
+
+

+The columns in the table are as follows:
+
+

+

+block size
+
The size in bytes of the checksummed blocks.
+
matches
+
The number of times a block of B was found in A.
+
tag hits
+
The number of times the 16 bit hash of the rolling
+checksum matched a hash of one of the checksums from B.
+
false alarms
+
The number of times the 32 bit rolling checksum
+  matched but the strong checksum didn't.
+
data
+
The amount of file data transferred verbatim, in bytes.
+
written
+
The total number of bytes written by 
+including protocol overheads. This is almost all file data.
+
read
+
The total number of bytes read by 
+including
+  protocol overheads. This is almost all checksum information.
+
+
+The results demonstrate that for block sizes above 300 bytes, only a
+small fraction (around 5%) of the file was transferred. The amount
+transferred was also considerably less than the size of the diff file
+that would have been transferred if the diff/patch method of updating
+a remote file was used.
+
+

+The checksums themselves took up a considerable amount of space,
+although much less than the size of the data transferred in each
+case. Each pair of checksums consumes 20 bytes: 4 bytes for the
+rolling checksum plus 16 bytes for the 128-bit MD4 checksum.
+
+

+The number of false alarms was less than 1/1000 of the number of
+true matches, indicating that the 32 bit rolling checksum is quite
+good at screening out false matches. 
+
+

+The number of tag hits indicates that the second level of the
+checksum search algorithm was invoked about once every 50
+characters.  This is quite high because the total number of blocks in
+the file is a large fraction of the size of the tag hash table. For
+smaller files we would expect the tag hit rate to be much closer to
+the number of matches.  For extremely large files, we should probably
+increase the size of the hash table.
+
+

+The next table shows similar results for a much smaller set of files.
+In this case the files were not packed into a tar file first. Rather,
+rsync was invoked with an option to recursively descend the directory
+tree. The files used were from two source releases of another software
+package called Samba. The total source code size is 1.7 MB and the
+diff between the two releases is 4155 lines long totalling 120 kB.
+
+

+

+

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ block  matches  tag  false  data  written  read
 size    hits  alarms      

+300 3727 3899 0 129775 153999 83948
500 2158 2325 0 171574 189330 50908
700 1517 1649 0 195024 210144 36828
900 1156 1281 0 222847 236471 29048
1100 921 1049 0 250073 262725 23988
+

+

+
+

+

+
+
+ 
+
+ 
+
+   
+

+ Next: Availability
+ Up: The rsync algorithm
+ Previous: Pipelining
+
+
+Andrew Tridgell
+
1998-11-09
+
+
+
diff --git a/rsync-web/tech_report/node7.html b/rsync-web/tech_report/node7.html
new file mode 100644
index 00000000..1f44ad46
--- /dev/null
+++ b/rsync-web/tech_report/node7.html
@@ -0,0 +1,62 @@
+
+
+
+
+Availability
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+
+ 
+
+   
+

+ Next: About this document ...
+ Up: The rsync algorithm
+ Previous: Results
+

+

+
+
+
+Availability
+
+
+
+An implementation of rsync which provides a convenient interface
+similar to the common UNIX command rcp has been written and is
+available for download from ftp://rsync.samba.org/pub/rsync.
+
+

+

+
+Andrew Tridgell
+
1998-11-09
+
+
+
diff --git a/rsync-web/tech_report/node8.html b/rsync-web/tech_report/node8.html
new file mode 100644
index 00000000..0bf88a51
--- /dev/null
+++ b/rsync-web/tech_report/node8.html
@@ -0,0 +1,61 @@
+
+
+
+
+About this document ... 
+
+
+
+
+
+
+
+
+
+
+
+ 
+
+ 
+
+   
+

+ Up: The rsync algorithm
+ Previous: Availability
+

+

+
+
+
+  About this document ... 
+ 
+ The rsync algorithm
+This document was generated using the
+LaTeX2HTML translator Version 98.1p1 release (March 2nd, 1998)
+

+Copyright © 1993, 1994, 1995, 1996, 1997,
+Nikos Drakos, 
+Computer Based Learning Unit, University of Leeds.
+

+The command line arguments were: 

+ latex2html tech_report.tex.
+

+The translation was initiated by Andrew Tridgell on 1998-11-09
+

+
+Andrew Tridgell
+
1998-11-09
+
+
+
diff --git a/rsync-web/tech_report/previous.gif b/rsync-web/tech_report/previous.gif
new file mode 100644
index 00000000..aef90f1f
Binary files /dev/null and b/rsync-web/tech_report/previous.gif differ
diff --git a/rsync-web/tech_report/tech_report.css b/rsync-web/tech_report/tech_report.css
new file mode 100644
index 00000000..4f86ccfc
--- /dev/null
+++ b/rsync-web/tech_report/tech_report.css
@@ -0,0 +1,19 @@
+
+/* Century Schoolbook font is very similar to Computer Modern Math: cmmi */
+.MATH    { font-family: "Century Schoolbook", serif; }
+.MATH I  { font-family: "Century Schoolbook", serif; font-weight: bold }
+.BOLDMATH { font-family: "Century Schoolbook", serif; font-weight: bold }
+
+/* implement both fixed-size and relative sizes */
+SMALL.XTINY		{ font-size : xx-small }
+SMALL.TINY		{ font-size : x-small  }
+SMALL.SCRIPTSIZE	{ font-size : smaller  }
+SMALL.FOOTNOTESIZE	{ font-size : small    }
+SMALL.SMALL		{  }
+BIG.LARGE		{  }
+BIG.XLARGE		{ font-size : large    }
+BIG.XXLARGE		{ font-size : x-large  }
+BIG.HUGE		{ font-size : larger   }
+BIG.XHUGE		{ font-size : xx-large }
+
+/* document-specific styles come next */
diff --git a/rsync-web/tech_report/tech_report.html b/rsync-web/tech_report/tech_report.html
new file mode 100644
index 00000000..77bf9fc2
--- /dev/null
+++ b/rsync-web/tech_report/tech_report.html
@@ -0,0 +1,94 @@
+
+
+
+
+The rsync algorithm
+
+
+
+
+
+
+
+
+
+
+
+ 
+ 
+   
+

+ Next: The problem
+

+

+
+
+
+
+

+
+

+
The rsync algorithm
+Andrew Tridgell         Paul Mackerras
+

+Department of Computer Science 

+Australian National University 

+Canberra, ACT 0200, Australia
+
+
+
+
+
Abstract:
+
+This report presents an algorithm for updating a file on one machine
+  to be identical to a file on another machine.  We assume that the
+  two machines are connected by a low-bandwidth high-latency
+  bi-directional communications link.  The algorithm identifies parts
+  of the source file which are identical to some part of the
+  destination file, and only sends those parts which cannot be matched
+  in this way.  Effectively, the algorithm computes a set of
+  differences without having both files on the same machine.  The
+  algorithm works best when the files are similar, but will also
+  function correctly and reasonably efficiently when the files are
+  quite different.
+
+
+

+

+
+ 
+
+The problem
+
The rsync algorithm
+
Rolling checksum
+
Checksum searching
+
Pipelining
+
Results
+
Availability
+
About this document ... 
+
+
+

+
+Andrew Tridgell
+
1998-11-09
+
+
+
diff --git a/rsync-web/tech_report/up.gif b/rsync-web/tech_report/up.gif
new file mode 100644
index 00000000..3d1aebf3
Binary files /dev/null and b/rsync-web/tech_report/up.gif differ
diff --git a/rsync-web/vger.txt b/rsync-web/vger.txt
new file mode 100644
index 00000000..da629c9a
--- /dev/null
+++ b/rsync-web/vger.txt
@@ -0,0 +1,35 @@
+The vger.rutgers.edu cvs tree is mirrored onto cvs.samba.org via
+anonymous rsync using the following script.
+
+    #!/bin/bash
+
+    cd /var/www/cvs/vger/
+    PATH=/usr/local/bin:/usr/freeware/bin:/usr/bin:/bin
+
+    RUN=`lps x | grep rsync | grep -v grep | wc -l`
+    if [ "$RUN" -gt 0 ]; then
+	    echo already running
+	    exit 1
+    fi
+
+    rsync -az vger.rutgers.edu::cvs/CVSROOT/ChangeLog $HOME/ChangeLog
+
+    sum1=`sum $HOME/ChangeLog`
+    sum2=`sum /var/www/cvs/vger/CVSROOT/ChangeLog`
+
+    if [ "$sum1" = "$sum2" ]; then
+	    echo nothing to do
+	    exit 0
+    fi
+
+    rsync -az --delete --force vger.rutgers.edu::cvs/ /var/www/cvs/vger/
+    exit 0
+
+Note in particular the initial rsync of the ChangeLog to determine if
+anything has changed. This could be omitted but it would mean that the
+rsyncd on vger would have to build a complete listing of the cvs area
+at each run. As most of the time nothing will have changed I wanted to
+save the time on vger by only doing a full rsync if the ChangeLog has
+changed. This helped quite a lot because vger is low on memory and
+generally quite heavily loaded, so doing a listing on such a large
+tree every hour would have been excessive.
diff --git a/rsync-web/win95.txt b/rsync-web/win95.txt
new file mode 100644
index 00000000..d856682f
--- /dev/null
+++ b/rsync-web/win95.txt
@@ -0,0 +1,110 @@
+Compiling rsync for MS Windows 95
+=================================
+
+Caveat: 
+There are no doubt other ways to do this, but I have not tried them.
+
+This will produce an rsync binary which runs under win95/NT which can _send_
+data to a UNIX rsync host but not receive. This is suitable for my requirements
+as I am backing up a bunch of win95 machines to a linux server, but it may
+not be what _you_ require.
+
+NOTE: I am now told (by patl@curl.com) that receiving as well as
+sending works with the current cygwin32 toolkit.
+
+
+Step 1. Get the Cygnus development kit
+--------------------------------------
+
+If you do not already know about this wonderful project undertaken by cygnus,
+grab the latest copy of the gnu-win32 runtime system from 
+
+    http://www.cygnus.com/misc/gnu-win32/
+
+You will want the CDK-B19.EXE self-installing binary (be warned - it's 12M
+in size) which contains gcc+binutils+DLLs required by the system. Read the
+instructions about this and install it. You will then have something which 
+looks _very_ close to a UNIX box as far as any UNIX software ic concerned.
+
+Also grab the updated version (B19.1) of the DLL as this fixes some problems
+(it's pretty small at ~190k).
+
+Take a bit of time to play with this stuff - have a look at the registry
+entries that define mount points etc so you know where/how your windows
+directories are mapped.
+
+Step 2. Compile rsync
+---------------------
+
+Once the magic BASH$ prompt appears in your cygnus dos box, you can download
+and compile rsync right out of the box. You might want to do this:
+
+    tar xvzf rsync-2.0.17.tar.gz  (or whatever version...)
+    cd rsync-2.0.17
+    chmod +x configure		(exec is not set automatically)
+    ./configure
+    make
+
+and you will have a working RSYNC.EXE
+
+Before you can do a "make install" you must edit the Makefile so that
+it knows about "rsync.exe" rather than "rsync".
+
+Step 3 (optional) - compile and install SSH
+-------------------------------------------
+
+If you want to use ssh as the transport then you better grab a copy and compile
+it - again, no surprises. It compiles ok under gnuwin32, and you can generate
+keys etc in the normal way.
+
+Problems
+--------
+
+Well, it _almost_ works seamlessly. Here are a couple of problems I have
+encountered so far - I do not know why these symptoms occur, and they are
+probably nothing to do with rsync, but if you follow this course then you
+will probably run into these things also...
+
+1. rsync will not _receive_ data onto a windows box. It seems to do everything
+   ok, but then hangs at the last step and no files actually appear. When
+   transferring via my modem, I can see data being received, but it never 
+   appears in my directory.
+
+NOTE: This now appears to be fixed.
+
+2. rsync, ssh and other gnuwin32-compiled programs can be called directly from
+   a DOS prompt, but argument passing seems to be broken. This means that
+   starting SSH directly is difficult.
+
+   After a bit of experimenting I found a workaround, which is not pretty
+   but worked for me :-)
+
+   Lets say you want to call ssh from a normal DOS prompt. Set up a batch
+   file called "SSH.BAT" which sets up the cygnus environment and calls bash
+   with the argument "ssh.sh %1 %2 %3 %4 %5 %6 %7 %8 %9". You can copy the
+   cygnus.bat file and use it as a template if you like. here is my ssh.bat:
+
+
+    @ECHO OFF
+    SET TERM=ansi
+    SET MAKE_MODE=unix
+    SET CYGFS=e:/apps/cygnus
+    SET GCC_EXEC_PREFIX=/lib\gcc-lib\
+    SET TCL_LIBRARY=%CYGROOT%\share\tcl8.0\
+    SET HOME=/home/awesley
+    SET GDBTK_LIBRARY=%CYGFS%/share/gdbtcl
+    bash /scripts/ssh.sh %1 %2 %3 %4 %5 %6 %7 %8 %9
+
+
+   Create a shell script called ssh.sh containing:
+
+    /usr/local/bin/ssh $*
+
+   which is then run by bash and calls the ssh binary (wherever you have
+   installed it).
+
+   I suspect that there is a better way, but I have not yet had time to 
+   look for it.
+
+
+Cheers, Anthony Wesley
diff --git a/rsync-web/y2k.html b/rsync-web/y2k.html
new file mode 100644
index 00000000..90cc7625
--- /dev/null
+++ b/rsync-web/y2k.html
@@ -0,0 +1,24 @@
+
+
+
+rsync y2k issues
+
+
+
+Year 2000 Issues
+
+We are starting to get a lot of Y2K compliance questions. The answer
+is that rsync has no Y2K problems. rsync uses 32 bit "seconds since
+1970" date formats and thus has no problems with the turn of the
+century.
+
+You must remember though that rsync is part of a larger system. It
+relies on a transport mechanism (rsh, ssh etc) and many operating
+systems services (such as inetd, syslog etc). If any of these other
+parts fail then rsync will of course be affected.

+
+Also remember that rsync comes with absolutely no warranty. It is up
+to you to test whether rsync is suitable in your computing environment,
+both before and after the turn of the century.
+
+


+ + home + FAQ + resources + features + examples + mailing lists + +	+ +	+ + bug-tracking + current issues and debugging + download + documentation + search + +
+ +

Frequently Asked Questions

rsync bug-tracking

How the DST Change can adversely affect FAT filesystems

Background

Mitigation

Correcting the Timestamps

Prevention

Notes and References

documentation

rsync download

Source-code releases

The GPG Signing Key

Binaries

Ubuntu

Git source vs Release files

Source repository patches

rsync examples

backup to a central backup server with 7 day incremental

backup to a spare disk

mirroring vger CVS tree

automated backup at home

Fancy footwork with remote file lists

rsync features

Search the rsync web pages

Using rsync through a firewall

Method 1 -- should work with any remote-shell

Method 2 -- requires ssh and nc (netcat)

Method 3 -- an alternate ssh method for those without nc (netcat)

Method 4 -- for using rsync in daemon-mode (requires nc)

Method 5 -- for using rsync in daemon-mode (for those without nc)

How Rsync WorksA Practical Overview

Foreword

Processes and Roles

Process Startup

The File List

The Pipeline

The Generator

The Sender

The Receiver

The Daemon

The Rsync Protocol

notes

Welcome to the rsync web pages

Rsync version 3.4.3 released

Rsync version 3.4.2 released

Rsync version 3.4.1 released

Rsync version 3.4.0 released

Rsync version 3.3.0 released

Rsync version 3.2.7 released

Rsync version 3.2.6 released

Rsync version 3.2.5 released

Rsync version 3.2.4 released

Rsync version 3.2.3 released

Rsync version 3.2.2 released

Rsync version 3.2.1 released

Rsync version 3.2.0 released

Rsync version 3.1.3 released

Rsync version 3.1.2 released

Rsync version 3.1.1 released

Rsync version 3.1.0 released

Rsync version 3.0.9 released

Rsync version 3.0.8 released

Rsync version 3.0.7 released

Rsync version 3.0.6 released

Rsync version 3.0.5 released

Rsync version 3.0.4 released

Rsync version 3.0.3 released

Rsync version 3.0.2 released

Rsync version 3.0.1 released

Rsync version 3.0.0 released

Rsync version 2.6.9 released

Rsync version 2.6.8 released

Rsync 2.6.7 released

Rsync 2.6.6 released

Rsync 2.6.5 released

Rsync 2.6.4 released

Rsync 2.6.3 released

Rsync 2.6.2 released

Rsync 2.6.1 released

One Cygwin hang-problem resolved

How Rsync Works
A Practical Overview