TODO

   1 -*- indented-text -*-
   2
   3 URGENT ---------------------------------------------------------------
   4
   5
   6 IMPORTANT ------------------------------------------------------------
   7
   8 Cross-test versions
   9
  10   Part of the regression suite should be making sure that we don't
  11   break backwards compatibility: old clients vs new servers and so
  12   on.  Ideally we would test the cross product of versions.
  13
  14   It might be sufficient to test downloads from well-known public
  15   rsync servers running different versions of rsync.  This will give
  16   some testing and also be the most common case for having different
  17   versions and not being able to upgrade.
  18
  19 use chroot
  20
  21   If the platform doesn't support it, then don't even try.
  22
  23   If running as non-root, then don't fail, just give a warning.
  24   (There was a thread about this a while ago?)
  25
  26     http://lists.samba.org/pipermail/rsync/2001-August/thread.html
  27     http://lists.samba.org/pipermail/rsync/2001-September/thread.html
  28
  29 --files-from
  30
  31   Avoids traversal.  Better option than a pile of --include statements
  32   for people who want to generate the file list using a find(1)
  33   command or a script.
  34
  35 Performance
  36
  37   Traverse just one directory at a time.  Tridge says it's possible.
  38
  39   At the moment rsync reads the whole file list into memory at the
  40   start, which makes us use a lot of memory and also not pipeline
  41   network access as much as we could.
  42
  43   We need to be careful of duplicate names getting into the file list.
  44   See clean_flist.  This could happen if multiple arguments include
  45   the same file.  Bad.
  46
  47   I think duplicates are only a problem if they're both flowing
  48   through the pipeline at the same time.  For example we might have
  49   updated the first occurrence after reading the checksums for the
  50   second.  So possibly we just need to make sure that we don't have
  51   both in the pipeline at the same time.
  52
  53   Possibly if we did one directory at a time that would be sufficient.
  54
  55   Alternatively we could pre-process the arguments to make sure no
  56   duplicates will ever be inserted.
  57
  58   We could have a hash table.
  59
  60 Memory accounting
  61
  62   At exit, show how much memory was used for the file list, etc.
  63
  64   Also we do a wierd exponential-growth allocation in flist.c.  I'm
  65   not sure this makes sense with modern mallocs.  At any rate it will
  66   make us allocate a huge amount of memory for large file lists.
  67
  68 Hard-link handling
  69
  70   At the moment hardlink handling is very expensive, so it's off by
  71   default.  It does not need to be so.
  72
  73   We can rule out hardlinked directories since they will probably
  74   screw us up in all kinds of ways.  They simply should not be used.
  75
  76   At the moment rsync only cares about hardlinks to regular files.  I
  77   guess you could also use them for sockets, devices and other beasts,
  78   but I have not seen them.
  79
  80   When trying to reproduce hard links, we only need to worry about
  81   files that have more than one name (nlinks>1 && !S_ISDIR).
  82
  83   The basic point of this is to discover alternate names that refer to
  84   the same file.  All operations, including creating the file and
  85   writing modifications to it need only to be done for the first name.
  86   For all later names, we just create the link and then leave it
  87   alone.
  88
  89   If hard links are to be preserved:
  90
  91     Before the generator/receiver fork, the list of files is received
  92     from the sender (recv_file_list), and a table for detecting hard
  93     links is built.
  94
  95     The generator looks for hard links within the file list and does
  96     not send checksums for them, though it does send other metadata.
  97
  98     The sender sends the device number and inode with file entries, so
  99     that files are uniquely identified.
 100
 101     The receiver goes through and creates hard links (do_hard_links)
 102     after all data has been written, but before directory permissions
 103     are set.
 104
 105   At the moment device and inum are sent as 4-byte integers, which
 106   will probably cause problems on large filesystems.  On Linux the
 107   kernel uses 64-bit ino_t's internally, and people will soon have
 108   filesystems big enough to use them.  We ought to follow NFS4 in
 109   using 64-bit device and inode identification, perhaps with a
 110   protocol version bump.
 111
 112   Once we've seen all the names for a particular file, we no longer
 113   need to think about it and we can deallocate the memory.
 114
 115   We can also have the case where there are links to a file that are
 116   not in the tree being transferred.  There's nothing we can do about
 117   that.  Because we rename the destination into place after writing,
 118   any hardlinks to the old file are always going to be orphaned.  In
 119   fact that is almost necessary because otherwise we'd get really
 120   confused if we were generating checksums for one name of a file and
 121   modifying another.
 122
 123   At the moment the code seems to make a whole second copy of the file
 124   list, which seems unnecessary.
 125
 126   We should have a test case that exercises hard links.  Since it
 127   might be hard to compare ./tls output where the inodes change we
 128   might need a little program to check whether several names refer to
 129   the same file.
 130
 131 IPv6
 132
 133   Implement suggestions from http://www.kame.net/newsletter/19980604/
 134   and ftp://ftp.iij.ad.jp/pub/RFC/rfc2553.txt
 135
 136   If a host has multiple addresses, then listen try to connect to all
 137   in order until we get through.  (getaddrinfo may return multiple
 138   addresses.)  This is kind of implemented already.
 139
 140   Possibly also when starting as a server we may need to listen on
 141   multiple passive addresses.  This might be a bit harder, because we
 142   may need to select on all of them.  Hm.
 143
 144   Define a syntax for IPv6 literal addresses.  Since they include
 145   colons, they tend to break most naming systems, including ours.
 146   Based on the HTTP IPv6 syntax, I think we should use
 147
 148      rsync://[::1]/foo/bar
 149      [::1]::bar
 150
 151   which should just take a small change to the parser code.
 152
 153 Errors
 154
 155   If we hang or get SIGINT, then explain where we were up to.  Perhaps
 156   have a static buffer that contains the current function name, or
 157   some kind of description of what we were trying to do.  This is a
 158   little easier on people than needing to run strace/truss.
 159
 160   "The dungeon collapses!  You are killed."  Rather than "unexpected
 161   eof" give a message that is more detailed if possible and also more
 162   helpful.
 163
 164 File attributes
 165
 166   Device major/minor numbers should be at least 32 bits each.  See
 167   http://lists.samba.org/pipermail/rsync/2001-November/005357.html
 168
 169   Transfer ACLs.  Need to think of a standard representation.
 170   Probably better not to even try to convert between NT and POSIX.
 171   Possibly can share some code with Samba.
 172
 173 Empty directories
 174
 175   With the current common --include '*/' --exclude '*' pattern, people
 176   can end up with many empty directories.  We might avoid this by
 177   lazily creating such directories.
 178
 179 zlib
 180
 181   Perhaps don't use our own zlib.  Will we actually be incompatible,
 182   or just be slightly less efficient?
 183
 184 logging
 185
 186   Perhaps flush stdout after each filename, so that people trying to
 187   monitor progress in a log file can do so more easily.  See
 188   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=48108
 189
 190 rsyncd over ssh
 191
 192   There are already some patches to do this.
 193
 194 PLATFORMS ------------------------------------------------------------
 195
 196 Win32
 197
 198   Don't detach, because this messes up --srvany.
 199
 200   http://sources.redhat.com/ml/cygwin/2001-08/msg00234.html
 201
 202   According to "Effective TCP/IP Programming" (??) close() on a socket
 203   has incorrect behaviour on Windows -- it sends a RST packet to the
 204   other side, which gives a "connection reset by peer" error.  On that
 205   platform we should probably do shutdown() instead.  However, on Unix
 206   we are correct to call close(), because shutdown() discards
 207   untransmitted data.
 208
 209 DOCUMENTATION --------------------------------------------------------
 210
 211 Update README
 212
 213 BUILD FARM -----------------------------------------------------------
 214
 215 Add machines
 216
 217   AMDAHL UTS (Dave Dykstra)
 218
 219   Cygwin (on different versions of Win32?)
 220
 221   HP-UX variants (via HP?)
 222
 223   SCO
 224
 225 NICE -----------------------------------------------------------------
 226
 227 SIGHUP
 228
 229   Re-read config file (just exec() ourselves) rather than exiting.
 230
 231 --no-detach and --no-fork options
 232
 233   Very useful for debugging.  Also good when running under a
 234   daemon-monitoring process that tries to restart the service when the
 235   parent exits.
 236
 237 hang/timeout friendliness
 238
 239   On
 240
 241 verbose output
 242
 243   Indicate whether files are new, updated, or deleted
 244
 245 internationalization
 246
 247   Change to using gettext().  Probably need to ship this for platforms
 248   that don't have it.
 249
 250   Solicit translations.
 251
 252   Does anyone care?
 253
 254 rsyncsh
 255
 256    Write a small emulation of interactive ftp as a Pythonn program
 257    that calls rsync.  Commands such as "cd", "ls", "ls *.c" etc map
 258    fairly directly into rsync commands: it just needs to remember the
 259    current host, directory and so on.  We can probably even do
 260    completion of remote filenames.
 261
 262 %K%