Notes about handling machines lacking getaddrinfo().

[rsync/rsync.git] / TODO

diff --git a/TODO b/TODO
index fe46584..13b3aad 100644 (file)
--- a/TODO
+++ b/TODO
@@ -2,6 +2,13 @@
 
 BUGS ---------------------------------------------------------------
 
 
 BUGS ---------------------------------------------------------------
 

+rsync-url barfs on upload
+
+  rsync foo rsync://localhost/transfer/
+
+  Fix the parser.
+
+

 There seems to be a bug with hardlinks
 
   mbp/2 build$ ls -l /tmp/a /tmp/b -i
 There seems to be a bug with hardlinks
 
   mbp/2 build$ ls -l /tmp/a /tmp/b -i


@@ -106,6 +113,10 @@ Cross-test versions
   some testing and also be the most common case for having different
   versions and not being able to upgrade.
 
   some testing and also be the most common case for having different
   versions and not being able to upgrade.
 

+--no-blocking-io might be broken
+
+  in the same way as --no-whole-file; somebody needs to check.
+

 
 DAEMON --------------------------------------------------------------
 
 
 DAEMON --------------------------------------------------------------
 


@@ -297,6 +308,15 @@ Hard-link handling
 
 IPv6
 
 
 IPv6
 

+  Put back the old socket code; if on a machine that does not properly
+  support the getaddrinfo API, then use it.  This is probably much
+  simpler than reimplementing it.  This might get us working again on
+  RedHat 5 and similar systems.  Although the Kame patch seems like a
+  good idea, in fact it is a much broader interface than the
+  relatively narrow "open by name", "accept and log" interface that
+  rsync uses internally, and it has the disadvantage of clashing with
+  half-arsed implementations of the API.
+

   Implement suggestions from http://www.kame.net/newsletter/19980604/
   and ftp://ftp.iij.ad.jp/pub/RFC/rfc2553.txt
 
   Implement suggestions from http://www.kame.net/newsletter/19980604/
   and ftp://ftp.iij.ad.jp/pub/RFC/rfc2553.txt