+ -- --
+
+
+Allow supplementary groups in rsyncd.conf 2002/04/09
+
+ Perhaps allow supplementary groups to be specified in rsyncd.conf;
+ then make the first one the primary gid and all the rest be
+ supplementary gids.
+
+ -- --
+
+
+Handling IPv6 on old machines
+
+ The KAME IPv6 patch is nice in theory but has proved a bit of a
+ nightmare in practice. The basic idea of their patch is that rsync
+ is rewritten to use the new getaddrinfo()/getnameinfo() interface,
+ rather than gethostbyname()/gethostbyaddr() as in rsync 2.4.6.
+ Systems that don't have the new interface are handled by providing
+ our own implementation in lib/, which is selectively linked in.
+
+ The problem with this is that it is really hard to get right on
+ platforms that have a half-working implementation, so redefining
+ these functions clashes with system headers, and leaving them out
+ breaks. This affects at least OSF/1, RedHat 5, and Cobalt, which
+ are moderately improtant.
+
+ Perhaps the simplest solution would be to 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.
+
+ In fact, our internal sockets interface (things like
+ open_socket_out(), etc) is much narrower than the getaddrinfo()
+ interface, and so probably simpler to get right. In addition, the
+ old code is known to work well on old machines.
+
+ We could drop the rather large lib/getaddrinfo files.
+
+ -- --
+
+
+Other IPv6 stuff:
+
+ Implement suggestions from http://www.kame.net/newsletter/19980604/
+ and ftp://ftp.iij.ad.jp/pub/RFC/rfc2553.txt
+
+ If a host has multiple addresses, then listen try to connect to all
+ in order until we get through. (getaddrinfo may return multiple
+ addresses.) This is kind of implemented already.
+
+ Possibly also when starting as a server we may need to listen on
+ multiple passive addresses. This might be a bit harder, because we
+ may need to select on all of them. Hm.
+
+ Define a syntax for IPv6 literal addresses. Since they include
+ colons, they tend to break most naming systems, including ours.
+ Based on the HTTP IPv6 syntax, I think we should use
+
+ rsync://[::1]/foo/bar [::1]::bar
+
+ which should just take a small change to the parser code.
+
+ -- --
+
+
+Add ACL support 2001/12/02
+
+ Transfer ACLs. Need to think of a standard representation.
+ Probably better not to even try to convert between NT and POSIX.
+ Possibly can share some code with Samba.
+
+ -- --
+
+
+Lazy directory creation
+
+ With the current common --include '*/' --exclude '*' pattern, people
+ can end up with many empty directories. We might avoid this by
+ lazily creating such directories.
+
+ -- --
+
+
+Conditional -z for old protocols
+
+ After we get the @RSYNCD greeting from the server, we know it's
+ version but we have not yet sent the command line, so we could just
+ remove the -z option if the server is too old.
+
+ For ssh invocation it's not so simple, because we actually use the
+ command line to start the remote process. However, we only actually
+ do compression in token.c, and we could therefore once we discover
+ the remote version emit an error if it's too old. I'm not sure if
+ that's a good tradeoff or not.
+
+ -- --
+
+
+proxy authentication 2002/01/23
+
+ Allow RSYNC_PROXY to be http://user:pass@proxy.foo:3128/, and do
+ HTTP Basic Proxy-Authentication.
+
+ Multiple schemes are possible, up to and including the insanity that
+ is NTLM, but Basic probably covers most cases.
+
+ -- --
+
+
+SOCKS 2002/01/23
+
+ Add --with-socks, and then perhaps a command-line option to put them
+ on or off. This might be more reliable than LD_PRELOAD hacks.
+
+ -- --
+
+
+FAT support
+
+ rsync to a FAT partition on a Unix machine doesn't work very well at
+ the moment. I think we get errors about invalid filenames and
+ perhaps also trying to do atomic renames.
+
+ I guess the code to do this is currently #ifdef'd on Windows;
+ perhaps we ought to intelligently fall back to it on Unix too.
+
+ -- --
+
+
+Allow forcing arbitrary permissions 2002/03/12
+
+ On 12 Mar 2002, Dave Dykstra <dwd@bell-labs.com> wrote:
+ > If we would add an option to do that functionality, I
+ > would vote for one that was more general which could mask
+ > off any set of permission bits and possibly add any set of
+ > bits. Perhaps a chmod-like syntax if it could be
+ > implemented simply.
+
+ I think that would be good too. For example, people uploading files
+ to a web server might like to say
+
+ rsync -avzP --chmod a+rX ./ sourcefrog.net:/home/www/sourcefrog/
+
+ Ideally the patch would implement as many of the gnu chmod semantics
+ as possible. I think the mode parser should be a separate function
+ that passes back something like (mask,set) description to the rest
+ of the program. For bonus points there would be a test case for the
+ parser.
+
+ Possibly also --chown
+
+ (Debian #23628)
+
+ -- --
+
+
+--diff david.e.sewell 2002/03/15
+
+ Allow people to specify the diff command. (Might want to use wdiff,
+ gnudiff, etc.)
+
+ Just diff the temporary file with the destination file, and delete
+ the tmp file rather than moving it into place.
+
+ Interaction with --partial.
+
+ Security interactions with daemon mode?
+
+ -- --
+
+
+Add daemon --no-detach and --no-fork options
+
+ Very useful for debugging. Also good when running under a
+ daemon-monitoring process that tries to restart the service when the
+ parent exits.
+
+ -- --
+
+
+Create more granular verbosity jw 2003/05/15
+
+ Control output with the --report option.
+
+ The option takes as a single argument (no whitespace) a
+ comma delimited lists of keywords.
+
+ This would separate debugging from "logging" as well as
+ fine grained selection of statistical reporting and what
+ actions are logged.
+
+ http://lists.samba.org/archive/rsync/2003-May/006059.html
+
+ -- --
+
+DOCUMENTATION --------------------------------------------------------
+
+Update README
+
+ -- --
+
+
+Keep list of open issues and todos on the web site
+
+ -- --
+
+
+Update web site from CVS
+
+ -- --
+
+
+Perhaps redo manual as SGML
+
+ The man page is getting rather large, and there is more information
+ that ought to be added.
+
+ TexInfo source is probably a dying format.
+
+ Linuxdoc looks like the most likely contender. I know DocBook is
+ favoured by some people, but it's so bloody verbose, even with emacs
+ support.
+
+ -- --
+
+LOGGING --------------------------------------------------------------
+
+Make dry run list all updates 2002/04/03
+
+ --dry-run is too dry
+
+ Mark Santcroos points out that -n fails to list files which have
+ only metadata changes, though it probably should.
+
+ There may be a Debian bug about this as well.
+
+ -- --
+
+
+Memory accounting
+
+ At exit, show how much memory was used for the file list, etc.
+
+ Also we do a wierd exponential-growth allocation in flist.c. I'm
+ not sure this makes sense with modern mallocs. At any rate it will
+ make us allocate a huge amount of memory for large file lists.
+
+ -- --
+
+
+Improve error messages
+
+ If we hang or get SIGINT, then explain where we were up to. Perhaps
+ have a static buffer that contains the current function name, or
+ some kind of description of what we were trying to do. This is a
+ little easier on people than needing to run strace/truss.
+
+ "The dungeon collapses! You are killed." Rather than "unexpected
+ eof" give a message that is more detailed if possible and also more
+ helpful.
+
+ If we get an error writing to a socket, then we should perhaps
+ continue trying to read to see if an error message comes across
+ explaining why the socket is closed. I'm not sure if this would
+ work, but it would certainly make our messages more helpful.
+
+ What happens if a directory is missing -x attributes. Do we lose
+ our load? (Debian #28416) Probably fixed now, but a test case would
+ be good.
+
+
+
+ -- --
+
+
+Better statistics: Rasmus 2002/03/08
+
+ <Rasmus>
+ hey, how about an rsync option that just gives you the
+ summary without the list of files? And perhaps gives
+ more information like the number of new files, number
+ of changed, deleted, etc. ?
+
+ <mbp>
+ nice idea there is --stats but at the moment it's very
+ tridge-oriented rather than user-friendly it would be
+ nice to improve it that would also work well with
+ --dryrun
+
+ -- --
+
+
+Perhaps flush stdout like syslog
+
+ Perhaps flush stdout after each filename, so that people trying to
+ monitor progress in a log file can do so more easily. See
+ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=48108
+
+ -- --
+
+
+Log deamon sessions that just list modules
+
+ At the connections that just get a list of modules are not logged,
+ but they should be.
+
+ -- --
+
+
+Log child death on signal
+
+ If a child of the rsync daemon dies with a signal, we should notice
+ that when we reap it and log a message.
+
+ -- --
+
+
+Keep stderr and stdout properly separated (Debian #23626)
+
+ -- --
+
+
+Log errors with function that reports process of origin
+
+ Use a separate function for reporting errors; prefix it with
+ "rsync:" or "rsync(remote)", or perhaps even "rsync(local
+ generator): ".
+
+ -- --
+
+
+verbose output David Stein 2001/12/20
+
+ Indicate whether files are new, updated, or deleted
+
+ At end of transfer, show how many files were or were not transferred
+ correctly.
+
+ -- --
+
+
+Add reason for transfer to file logging
+
+ Explain *why* every file is transferred or not (e.g. "local mtime
+ 123123 newer than 1283198")
+
+ -- --
+
+
+debugging of daemon 2002/04/08
+
+ Add an rsyncd.conf parameter to turn on debugging on the server.
+
+ -- --
+
+
+internationalization
+
+ Change to using gettext(). Probably need to ship this for platforms
+ that don't have it.
+
+ Solicit translations.
+
+ Does anyone care? Before we bother modifying the code, we ought to
+ get the manual translated first, because that's possibly more useful
+ and at any rate demonstrates desire.
+
+ -- --
+
+DEVELOPMENT --------------------------------------------------------
+
+Handling duplicate names
+
+ We need to be careful of duplicate names getting into the file list.
+ See clean_flist(). This could happen if multiple arguments include
+ the same file. Bad.
+
+ I think duplicates are only a problem if they're both flowing
+ through the pipeline at the same time. For example we might have
+ updated the first occurrence after reading the checksums for the
+ second. So possibly we just need to make sure that we don't have
+ both in the pipeline at the same time.
+
+ Possibly if we did one directory at a time that would be sufficient.
+
+ Alternatively we could pre-process the arguments to make sure no
+ duplicates will ever be inserted. There could be some bad cases
+ when we're collapsing symlinks.
+
+ We could have a hash table.
+
+ The root of the problem is that we do not want more than one file
+ list entry referring to the same file. At first glance there are
+ several ways this could happen: symlinks, hardlinks, and repeated
+ names on the command line.
+
+ If names are repeated on the command line, they may be present in
+ different forms, perhaps by traversing directory paths in different
+ ways, traversing paths including symlinks. Also we need to allow
+ for expansion of globs by rsync.
+
+ At the moment, clean_flist() requires having the entire file list in
+ memory. Duplicate names are detected just by a string comparison.
+
+ We don't need to worry about hard links causing duplicates because
+ files are never updated in place. Similarly for symlinks.
+
+ I think even if we're using a different symlink mode we don't need
+ to worry.
+
+ Unless we're really clever this will introduce a protocol
+ incompatibility, so we need to be able to accept the old format as
+ well.
+
+ -- --
+
+
+Use generic zlib 2002/02/25
+
+ Perhaps don't use our own zlib.
+
+ Advantages:
+
+ - will automatically be up to date with bugfixes in zlib
+
+ - can leave it out for small rsync on e.g. recovery disks
+
+ - can use a shared library
+
+ - avoids people breaking rsync by trying to do this themselves and
+ messing up
+
+ Should we ship zlib for systems that don't have it, or require
+ people to install it separately?
+
+ Apparently this will make us incompatible with versions of rsync
+ that use the patched version of rsync. Probably the simplest way to
+ do this is to just disable gzip (with a warning) when talking to old
+ versions.
+
+ -- --
+
+
+TDB: 2002/03/12
+
+ Rather than storing the file list in memory, store it in a TDB.
+
+ This *might* make memory usage lower while building the file list.
+
+ Hashtable lookup will mean files are not transmitted in order,
+ though... hm.
+
+ This would neatly eliminate one of the major post-fork shared data
+ structures.
+
+ -- --
+
+
+Splint 2002/03/12
+
+ Build rsync with SPLINT to try to find security holes. Add
+ annotations as necessary. Keep track of the number of warnings
+ found initially, and see how many of them are real bugs, or real
+ security bugs. Knowing the percentage of likely hits would be
+ really interesting for other projects.
+
+ -- --
+
+
+Memory debugger
+
+ jra recommends Valgrind:
+
+ http://devel-home.kde.org/~sewardj/
+
+ -- --
+
+
+Create release script
+
+ Script would:
+
+ Update spec files
+
+ Build tar file; upload
+
+ Send announcement to mailing list and c.o.l.a.
+
+ Make freshmeat announcement
+
+ Update web site
+
+ -- --
+
+
+Add machines to build farm
+
+ Cygwin (on different versions of Win32?)
+
+ HP-UX variants (via HP?)
+
+ SCO
+