X-Git-Url: https://mattmccutchen.net/rsync/rsync.git/blobdiff_plain/8bd1a73e14bc1efb9bab01fbd1d693725183cca3..32e83406c4e1a6face6088f7cb7d486577be2d6d:/TODO

diff --git a/TODO b/TODO
index 704e5793..b369a960 100644
--- a/TODO
+++ b/TODO
@@ -99,9 +99,11 @@ Progress indicator can produce corrupt output when transferring directories:
   main/binary-arm/math/
   main/binary-arm/misc/
 
+
 lchmod
   I don't think we handle this properly on systems that don't have the
-  call.
+  call.  Are there any such?
+
 
 Cross-test versions
   Part of the regression suite should be making sure that we don't
@@ -138,7 +140,7 @@ rsyncd over ssh
 FEATURES ------------------------------------------------------------
 
 
---dry-run is insufficiently dry
+--dry-run is too dry
 
   Mark Santcroos points out that -n fails to list files which have
   only metadata changes, though it probably should.  
@@ -313,14 +315,21 @@ Hard-link handling
 
 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.
+  Perhaps 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.
+
+  Alternatively, have two different files implementing the same
+  interface, and choose either the new or the old API.  This is
+  probably necessary for systems that e.g. have IPv6, but
+  gethostbyaddr() can't handle it.  The Linux manpage claims this is
+  currently the case.
+
+  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