Note about lchmod.
[rsync.git] / TODO
1 -*- indented-text -*-
2
3 BUGS ---------------------------------------------------------------
4
5 rsync-url barfs on upload
6
7   rsync foo rsync://localhost/transfer/
8
9   Fix the parser.
10
11
12 There seems to be a bug with hardlinks
13
14   mbp/2 build$ ls -l /tmp/a /tmp/b -i
15   /tmp/a:
16   total 32
17   2568307 -rw-rw-r--    3 mbp      mbp            29 Mar 25 17:30 a1
18   2568307 -rw-rw-r--    3 mbp      mbp            29 Mar 25 17:30 a2
19   2568307 -rw-rw-r--    3 mbp      mbp            29 Mar 25 17:30 a3
20   2568310 -rw-rw-r--    5 mbp      mbp            29 Mar 25 17:30 a4
21   2568310 -rw-rw-r--    5 mbp      mbp            29 Mar 25 17:30 a5
22   2568310 -rw-rw-r--    5 mbp      mbp            29 Mar 25 17:30 b1
23   2568310 -rw-rw-r--    5 mbp      mbp            29 Mar 25 17:30 b2
24   2568310 -rw-rw-r--    5 mbp      mbp            29 Mar 25 17:30 b3
25
26   /tmp/b:
27   total 32
28   2568309 -rw-rw-r--    3 mbp      mbp            29 Mar 25 17:30 a1
29   2568309 -rw-rw-r--    3 mbp      mbp            29 Mar 25 17:30 a2
30   2568309 -rw-rw-r--    3 mbp      mbp            29 Mar 25 17:30 a3
31   2568311 -rw-rw-r--    5 mbp      mbp            29 Mar 25 17:30 a4
32   2568311 -rw-rw-r--    5 mbp      mbp            29 Mar 25 17:30 a5
33   2568311 -rw-rw-r--    5 mbp      mbp            29 Mar 25 17:30 b1
34   2568311 -rw-rw-r--    5 mbp      mbp            29 Mar 25 17:30 b2
35   2568311 -rw-rw-r--    5 mbp      mbp            29 Mar 25 17:30 b3
36   mbp/2 build$ rm -r /tmp/b && ./rsync -avH /tmp/a/ /tmp/b
37   building file list ... done
38   created directory /tmp/b
39   ./
40   a1
41   a4
42   a2 => a1
43   a3 => a2
44   wrote 350 bytes  read 52 bytes  804.00 bytes/sec
45   total size is 232  speedup is 0.58
46   mbp/2 build$ rm -r /tmp/b
47   mbp/2 build$ ls -l /tmp/b
48   ls: /tmp/b: No such file or directory
49   mbp/2 build$ rm -r /tmp/b && ./rsync -avH /tmp/a/ /tmp/b
50   rm: cannot remove `/tmp/b': No such file or directory
51   mbp/2 build$ rm -f -r /tmp/b && ./rsync -avH /tmp/a/ /tmp/b
52   building file list ... done
53   created directory /tmp/b
54   ./
55   a1
56   a4
57   a2 => a1
58   a3 => a2
59   wrote 350 bytes  read 52 bytes  804.00 bytes/sec
60   total size is 232  speedup is 0.58
61   mbp/2 build$ ls -l /tmp/b
62   total 32
63   -rw-rw-r--    3 mbp      mbp            29 Mar 25 17:30 a1
64   -rw-rw-r--    3 mbp      mbp            29 Mar 25 17:30 a2
65   -rw-rw-r--    3 mbp      mbp            29 Mar 25 17:30 a3
66   -rw-rw-r--    5 mbp      mbp            29 Mar 25 17:30 a4
67   -rw-rw-r--    5 mbp      mbp            29 Mar 25 17:30 a5
68   -rw-rw-r--    5 mbp      mbp            29 Mar 25 17:30 b1
69   -rw-rw-r--    5 mbp      mbp            29 Mar 25 17:30 b2
70   -rw-rw-r--    5 mbp      mbp            29 Mar 25 17:30 b3
71   mbp/2 build$ ls -l /tmp/a
72   total 32
73   -rw-rw-r--    3 mbp      mbp            29 Mar 25 17:30 a1
74   -rw-rw-r--    3 mbp      mbp            29 Mar 25 17:30 a2
75   -rw-rw-r--    3 mbp      mbp            29 Mar 25 17:30 a3
76   -rw-rw-r--    5 mbp      mbp            29 Mar 25 17:30 a4
77   -rw-rw-r--    5 mbp      mbp            29 Mar 25 17:30 a5
78   -rw-rw-r--    5 mbp      mbp            29 Mar 25 17:30 b1
79   -rw-rw-r--    5 mbp      mbp            29 Mar 25 17:30 b2
80   -rw-rw-r--    5 mbp      mbp            29 Mar 25 17:30 b3
81
82
83 Progress indicator can produce corrupt output when transferring directories:
84
85   main/binary-arm/
86   main/binary-arm/admin/
87   main/binary-arm/base/
88   main/binary-arm/comm/8.56kB/s    0:00:52
89   main/binary-arm/devel/
90   main/binary-arm/doc/
91   main/binary-arm/editors/
92   main/binary-arm/electronics/s    0:00:53
93   main/binary-arm/games/
94   main/binary-arm/graphics/
95   main/binary-arm/hamradio/
96   main/binary-arm/interpreters/
97   main/binary-arm/libs/6.61kB/s    0:00:54
98   main/binary-arm/mail/
99   main/binary-arm/math/
100   main/binary-arm/misc/
101
102
103 lchmod
104   I don't think we handle this properly on systems that don't have the
105   call.  Are there any such?
106
107
108 Cross-test versions
109   Part of the regression suite should be making sure that we don't
110   break backwards compatibility: old clients vs new servers and so
111   on.  Ideally we would test the cross product of versions.  
112
113   It might be sufficient to test downloads from well-known public
114   rsync servers running different versions of rsync.  This will give
115   some testing and also be the most common case for having different
116   versions and not being able to upgrade.
117
118 --no-blocking-io might be broken
119
120   in the same way as --no-whole-file; somebody needs to check.
121
122 Do not rely on having a group called "nobody"
123
124   http://www.linuxbase.org/spec/refspecs/LSB_1.1.0/gLSB/usernames.html
125
126   On Debian it's "nogroup"
127
128 DAEMON --------------------------------------------------------------
129
130 server-imposed bandwidth limits
131
132 rsyncd over ssh
133
134   There are already some patches to do this.
135
136   BitKeeper uses a server whose login shell is set to bkd.  That's
137   probably a reasonable approach.
138
139
140 FEATURES ------------------------------------------------------------
141
142
143 --dry-run is insufficiently dry
144
145   Mark Santcroos points out that -n fails to list files which have
146   only metadata changes, though it probably should.  
147
148   There may be a Debian bug about this as well.
149
150
151 use chroot
152
153   If the platform doesn't support it, then don't even try.
154
155   If running as non-root, then don't fail, just give a warning.
156   (There was a thread about this a while ago?)
157
158     http://lists.samba.org/pipermail/rsync/2001-August/thread.html
159     http://lists.samba.org/pipermail/rsync/2001-September/thread.html
160
161
162 --files-from
163
164   Avoids traversal.  Better option than a pile of --include statements
165   for people who want to generate the file list using a find(1)
166   command or a script.
167
168
169 supplementary groups
170
171   Perhaps allow supplementary groups to be specified in rsyncd.conf;
172   then make the first one the primary gid and all the rest be
173   supplementary gids.
174
175
176 File list structure in memory
177
178   Rather than one big array, perhaps have a tree in memory mirroring
179   the directory tree.  
180
181   This might make sorting much faster!  (I'm not sure it's a big CPU
182   problem, mind you.)  
183
184   It might also reduce memory use in storing repeated directory names
185   -- again I'm not sure this is a problem.
186
187 Performance
188
189   Traverse just one directory at a time.  Tridge says it's possible.
190
191   At the moment rsync reads the whole file list into memory at the
192   start, which makes us use a lot of memory and also not pipeline
193   network access as much as we could.
194
195
196 Handling duplicate names
197
198   We need to be careful of duplicate names getting into the file list.
199   See clean_flist().  This could happen if multiple arguments include
200   the same file.  Bad.
201
202   I think duplicates are only a problem if they're both flowing
203   through the pipeline at the same time.  For example we might have
204   updated the first occurrence after reading the checksums for the
205   second.  So possibly we just need to make sure that we don't have
206   both in the pipeline at the same time.  
207
208   Possibly if we did one directory at a time that would be sufficient.
209
210   Alternatively we could pre-process the arguments to make sure no
211   duplicates will ever be inserted.  There could be some bad cases
212   when we're collapsing symlinks.
213
214   We could have a hash table.
215
216   The root of the problem is that we do not want more than one file
217   list entry referring to the same file.  At first glance there are
218   several ways this could happen: symlinks, hardlinks, and repeated
219   names on the command line.
220
221   If names are repeated on the command line, they may be present in
222   different forms, perhaps by traversing directory paths in different
223   ways, traversing paths including symlinks.  Also we need to allow
224   for expansion of globs by rsync.
225
226   At the moment, clean_flist() requires having the entire file list in
227   memory.  Duplicate names are detected just by a string comparison.
228
229   We don't need to worry about hard links causing duplicates because
230   files are never updated in place.  Similarly for symlinks.
231
232   I think even if we're using a different symlink mode we don't need
233   to worry.
234
235   Unless we're really clever this will introduce a protocol
236   incompatibility, so we need to be able to accept the old format as
237   well.
238
239
240 Memory accounting
241
242   At exit, show how much memory was used for the file list, etc.
243
244   Also we do a wierd exponential-growth allocation in flist.c.  I'm
245   not sure this makes sense with modern mallocs.  At any rate it will
246   make us allocate a huge amount of memory for large file lists.
247
248
249 Hard-link handling
250
251   At the moment hardlink handling is very expensive, so it's off by
252   default.  It does not need to be so.  
253
254   Since most of the solutions are rather intertwined with the file
255   list it is probably better to fix that first, although fixing
256   hardlinks is possibly simpler.
257
258   We can rule out hardlinked directories since they will probably
259   screw us up in all kinds of ways.  They simply should not be used.
260
261   At the moment rsync only cares about hardlinks to regular files.  I
262   guess you could also use them for sockets, devices and other beasts,
263   but I have not seen them.
264
265   When trying to reproduce hard links, we only need to worry about
266   files that have more than one name (nlinks>1 && !S_ISDIR). 
267
268   The basic point of this is to discover alternate names that refer to
269   the same file.  All operations, including creating the file and
270   writing modifications to it need only to be done for the first name.
271   For all later names, we just create the link and then leave it
272   alone.
273
274   If hard links are to be preserved:
275
276     Before the generator/receiver fork, the list of files is received
277     from the sender (recv_file_list), and a table for detecting hard
278     links is built.
279
280     The generator looks for hard links within the file list and does
281     not send checksums for them, though it does send other metadata.
282
283     The sender sends the device number and inode with file entries, so
284     that files are uniquely identified.
285
286     The receiver goes through and creates hard links (do_hard_links)
287     after all data has been written, but before directory permissions
288     are set.
289
290   At the moment device and inum are sent as 4-byte integers, which
291   will probably cause problems on large filesystems.  On Linux the
292   kernel uses 64-bit ino_t's internally, and people will soon have
293   filesystems big enough to use them.  We ought to follow NFS4 in
294   using 64-bit device and inode identification, perhaps with a
295   protocol version bump.
296
297   Once we've seen all the names for a particular file, we no longer
298   need to think about it and we can deallocate the memory.
299
300   We can also have the case where there are links to a file that are
301   not in the tree being transferred.  There's nothing we can do about
302   that.  Because we rename the destination into place after writing,
303   any hardlinks to the old file are always going to be orphaned.  In
304   fact that is almost necessary because otherwise we'd get really
305   confused if we were generating checksums for one name of a file and
306   modifying another.
307
308   At the moment the code seems to make a whole second copy of the file
309   list, which seems unnecessary.
310
311   We should have a test case that exercises hard links.  Since it
312   might be hard to compare ./tls output where the inodes change we
313   might need a little program to check whether several names refer to
314   the same file.
315
316 IPv6
317
318   Perhaps put back the old socket code; if on a machine that does not
319   properly support the getaddrinfo API, then use it.  This is probably
320   much simpler than reimplementing it.
321
322   Alternatively, have two different files implementing the same
323   interface, and choose either the new or the old API.  This is
324   probably necessary for systems that e.g. have IPv6, but
325   gethostbyaddr() can't handle it.  The Linux manpage claims this is
326   currently the case.
327
328   This might get us working again on RedHat 5 and similar systems.
329   Although the Kame patch seems like a good idea, in fact it is a much
330   broader interface than the relatively narrow "open by name", "accept
331   and log" interface that rsync uses internally, and it has the
332   disadvantage of clashing with half-arsed implementations of the API.
333
334   Implement suggestions from http://www.kame.net/newsletter/19980604/
335   and ftp://ftp.iij.ad.jp/pub/RFC/rfc2553.txt
336
337   If a host has multiple addresses, then listen try to connect to all
338   in order until we get through.  (getaddrinfo may return multiple
339   addresses.)  This is kind of implemented already.
340
341   Possibly also when starting as a server we may need to listen on
342   multiple passive addresses.  This might be a bit harder, because we
343   may need to select on all of them.  Hm.
344
345   Define a syntax for IPv6 literal addresses.  Since they include
346   colons, they tend to break most naming systems, including ours.
347   Based on the HTTP IPv6 syntax, I think we should use
348  
349      rsync://[::1]/foo/bar
350      [::1]::bar
351
352   which should just take a small change to the parser code.
353
354
355 Errors
356
357   If we hang or get SIGINT, then explain where we were up to.  Perhaps
358   have a static buffer that contains the current function name, or
359   some kind of description of what we were trying to do.  This is a
360   little easier on people than needing to run strace/truss.
361
362   "The dungeon collapses!  You are killed."  Rather than "unexpected
363   eof" give a message that is more detailed if possible and also more
364   helpful.  
365
366   If we get an error writing to a socket, then we should perhaps
367   continue trying to read to see if an error message comes across
368   explaining why the socket is closed.  I'm not sure if this would
369   work, but it would certainly make our messages more helpful.
370
371   What happens if a directory is missing -x attributes.  Do we lose
372   our load?  (Debian #28416)  Probably fixed now, but a test case
373   would be good.
374
375
376 File attributes
377
378   Device major/minor numbers should be at least 32 bits each.  See
379   http://lists.samba.org/pipermail/rsync/2001-November/005357.html
380
381   Transfer ACLs.  Need to think of a standard representation.
382   Probably better not to even try to convert between NT and POSIX.
383   Possibly can share some code with Samba.
384
385 Empty directories
386
387   With the current common --include '*/' --exclude '*' pattern, people
388   can end up with many empty directories.  We might avoid this by
389   lazily creating such directories.
390
391
392 zlib
393
394   Perhaps don't use our own zlib.  
395
396   Advantages:
397    
398     - will automatically be up to date with bugfixes in zlib
399
400     - can leave it out for small rsync on e.g. recovery disks
401
402     - can use a shared library
403
404     - avoids people breaking rsync by trying to do this themselves and
405       messing up
406
407   Should we ship zlib for systems that don't have it, or require
408   people to install it separately?
409
410   Apparently this will make us incompatible with versions of rsync
411   that use the patched version of rsync.  Probably the simplest way to
412   do this is to just disable gzip (with a warning) when talking to old
413   versions.
414
415
416 logging
417
418   Perhaps flush stdout after each filename, so that people trying to
419   monitor progress in a log file can do so more easily.  See
420   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=48108
421
422   At the connections that just get a list of modules are not logged,
423   but they should be.
424
425   If a child of the rsync daemon dies with a signal, we should notice
426   that when we reap it and log a message.
427
428   Keep stderr and stdout properly separated (Debian #23626)
429
430   After we get the @RSYNCD greeting from the server, we know it's
431   version but we have not yet sent the command line, so we could just
432   remove the -z option if the server is too old.  
433
434   For ssh invocation it's not so simple, because we actually use the
435   command line to start the remote process.  However, we only actually
436   do compression in token.c, and we could therefore once we discover
437   the remote version emit an error if it's too old.  I'm not sure if
438   that's a good tradeoff or not.
439
440
441 rsyncd over ssh
442
443   There are already some patches to do this.
444
445 proxy authentication
446
447   Allow RSYNC_PROXY to be http://user:pass@proxy.foo:3128/, and do
448   HTTP Basic Proxy-Authentication.  
449
450   Multiple schemes are possible, up to and including the insanity that
451   is NTLM, but Basic probably covers most cases.
452
453 SOCKS
454
455   Add --with-socks, and then perhaps a command-line option to put them
456   on or off.  This might be more reliable than LD_PRELOAD hacks.
457
458 FAT support
459
460   rsync to a FAT partition on a Unix machine doesn't work very well
461   at the moment.  I think we get errors about invalid filenames and 
462   perhaps also trying to do atomic renames.
463
464   I guess the code to do this is currently #ifdef'd on Windows; perhaps
465   we ought to intelligently fall back to it on Unix too.
466
467
468 Better statistics:
469
470   <Rasmus> mbp: hey, how about an rsync option that just gives you the
471   summary without the list of files?  And perhaps gives more
472   information like the number of new files, number of changed,
473   deleted, etc. ?
474   <mbp> Rasmus: nice idea
475   <mbp> there is --stats
476   <mbp> but at the moment it's very tridge-oriented
477   <mbp> rather than user-friendly
478   <mbp> it would be nice to improve it
479   <mbp> that would also work well with --dryrun
480
481 TDB:
482
483   Rather than storing the file list in memory, store it in a TDB.
484
485   This *might* make memory usage lower while building the file list.
486
487   Hashtable lookup will mean files are not transmitted in order,
488   though... hm.
489
490   This would neatly eliminate one of the major post-fork shared data
491   structures.
492
493
494 chmod:
495
496   On 12 Mar 2002, Dave Dykstra <dwd@bell-labs.com> wrote:
497   > If we would add an option to do that functionality, I would vote for one
498   > that was more general which could mask off any set of permission bits and
499   > possibly add any set of bits.  Perhaps a chmod-like syntax if it could be
500   > implemented simply.
501
502   I think that would be good too.  For example, people uploading files   
503   to a web server might like to say
504
505   rsync -avzP --chmod a+rX ./ sourcefrog.net:/home/www/sourcefrog/
506
507   Ideally the patch would implement as many of the gnu chmod semantics
508   as possible.  I think the mode parser should be a separate function
509   that passes back something like (mask,set) description to the rest of
510   the program.  For bonus points there would be a test case for the  
511   parser.
512
513   Possibly also --chown
514
515   (Debian #23628)
516
517
518 --diff
519
520   Allow people to specify the diff command.  (Might want to use wdiff,
521   gnudiff, etc.)
522
523   Just diff the temporary file with the destination file, and delete
524   the tmp file rather than moving it into place.
525
526   Interaction with --partial.
527
528   Security interactions with daemon mode?
529
530   (Suggestion from david.e.sewell)
531
532
533 Incorrect timestamps (Debian #100295)
534
535   A bit hard to believe, but apparently it happens.
536
537
538 Check "refuse options works"
539
540   We need a test case for this...
541
542   Was this broken when we changed to popt?
543
544
545 PERFORMANCE ----------------------------------------------------------
546
547 MD4 file_sum
548
549   If we're doing a local transfer, or using -W, then perhaps don't
550   send the file checksum.  If we're doing a local transfer, then
551   calculating MD4 checksums uses 90% of CPU and is unlikely to be
552   useful.
553
554   Indeed for transfers over zlib or ssh we can also rely on the
555   transport to have quite strong protection against corruption.
556
557   Perhaps we should have an option to disable this, analogous to
558   --whole-file, although it would default to disabled.  The file
559   checksum takes up a definite space in the protocol -- we can either
560   set it to 0, or perhaps just leave it out.
561
562 MD4
563
564   Perhaps borrow an assembler MD4 from someone?
565
566   Make sure we call MD4 with properly-sized blocks whenever possible
567   to avoid copying into the residue region?
568
569 String area code
570
571   Test whether this is actually faster than just using malloc().  If
572   it's not (anymore), throw it out.
573           
574
575 PLATFORMS ------------------------------------------------------------
576
577 Win32
578
579   Don't detach, because this messes up --srvany.
580
581   http://sources.redhat.com/ml/cygwin/2001-08/msg00234.html
582
583   According to "Effective TCP/IP Programming" (??) close() on a socket
584   has incorrect behaviour on Windows -- it sends a RST packet to the
585   other side, which gives a "connection reset by peer" error.  On that
586   platform we should probably do shutdown() instead.  However, on Unix
587   we are correct to call close(), because shutdown() discards
588   untransmitted data.
589
590
591 DEVELOPMENT ----------------------------------------------------------
592
593 Splint
594
595   Build rsync with SPLINT to try to find security holes.  Add
596   annotations as necessary.  Keep track of the number of warnings
597   found initially, and see how many of them are real bugs, or real
598   security bugs.  Knowing the percentage of likely hits would be
599   really interesting for other projects.
600
601 Torture test
602
603   Something that just keeps running rsync continuously over a data set
604   likely to generate problems.
605
606 Cross-testing
607
608   Run current rsync versions against significant past releases.
609
610 Memory debugger
611
612   jra recommends Valgrind:
613
614     http://devel-home.kde.org/~sewardj/
615
616 Release script
617   
618   Update spec files
619
620   Build tar file; upload
621
622   Send announcement to mailing list and c.o.l.a.
623   
624   Make freshmeat announcement
625
626   Update web site
627
628
629
630 TESTING --------------------------------------------------------------
631
632 Cross-test versions
633
634   Part of the regression suite should be making sure that we don't
635   break backwards compatibility: old clients vs new servers and so
636   on.  Ideally we would test both up and down from the current release
637   to all old versions.
638
639   We might need to omit broken old versions, or versions in which
640   particular functionality is broken
641
642   It might be sufficient to test downloads from well-known public
643   rsync servers running different versions of rsync.  This will give
644   some testing and also be the most common case for having different
645   versions and not being able to upgrade.
646
647
648 Test on kernel source
649
650   Download all versions of kernel; unpack, sync between them.  Also
651   sync between uncompressed tarballs.  Compare directories after
652   transfer.
653
654   Use local mode; ssh; daemon; --whole-file and --no-whole-file.
655
656   Use awk to pull out the 'speedup' number for each transfer.  Make
657   sure it is >= x.
658
659
660 Test large files
661
662   Sparse and non-sparse
663
664 Mutator program
665
666   Insert bytes, delete bytes, swap blocks, ...
667
668 configure option to enable dangerous tests
669
670 If tests are skipped, say why.
671
672 Test daemon feature to disallow particular options.
673
674 Pipe program that makes slow/jerky connections.
675
676 Versions of read() and write() that corrupt the stream, or abruptly fail
677
678 Separate makefile target to run rough tests -- or perhaps just run
679 them every time?
680
681 Test "refuse options" works
682
683   What about for --recursive?
684
685   If you specify an unrecognized option here, you should get an error.
686
687
688 DOCUMENTATION --------------------------------------------------------
689
690 Update README
691
692 Keep list of open issues and todos on the web site
693
694 Update web site from CVS
695
696
697 Perhaps redo manual as SGML
698
699   The man page is getting rather large, and there is more information
700   that ought to be added.
701
702   TexInfo source is probably a dying format.
703
704   Linuxdoc looks like the most likely contender.  I know DocBook is
705   favoured by some people, but it's so bloody verbose, even with emacs
706   support.
707
708
709 BUILD FARM -----------------------------------------------------------
710
711 Add machines
712
713   AMDAHL UTS (Dave Dykstra)
714
715   Cygwin (on different versions of Win32?)
716
717   HP-UX variants (via HP?)
718
719   SCO
720
721
722 LOGGING --------------------------------------------------------------
723
724   Perhaps flush stdout after each filename, so that people trying to
725   monitor progress in a log file can do so more easily.  See
726   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=48108
727
728   At the connections that just get a list of modules are not logged,
729   but they should be.
730
731   If a child of the rsync daemon dies with a signal, we should notice
732   that when we reap it and log a message.
733
734   Keep stderr and stdout properly separated (Debian #23626)
735
736   Use a separate function for reporting errors; prefix it with
737   "rsync:" or "rsync(remote)", or perhaps even "rsync(local
738   generator): ".
739
740 verbose output
741   
742   Indicate whether files are new, updated, or deleted
743
744   At end of transfer, show how many files were or were not transferred
745   correctly.
746
747 -vv
748
749   Explain *why* every file is transferred or not (e.g. "local mtime
750   123123 newer than 1283198")
751
752
753 debugging of daemon
754
755   Add an rsyncd.conf parameter to turn on debugging on the server.
756
757
758
759 NICE -----------------------------------------------------------------
760
761 --no-detach and --no-fork options
762
763   Very useful for debugging.  Also good when running under a
764   daemon-monitoring process that tries to restart the service when the
765   parent exits.
766
767 hang/timeout friendliness
768
769 internationalization
770
771   Change to using gettext().  Probably need to ship this for platforms
772   that don't have it.  
773
774   Solicit translations.
775
776   Does anyone care?  Before we bother modifying the code, we ought to
777   get the manual translated first, because that's possibly more useful
778   and at any rate demonstrates desire.
779
780 rsyncsh 
781
782    Write a small emulation of interactive ftp as a Pythonn program
783    that calls rsync.  Commands such as "cd", "ls", "ls *.c" etc map
784    fairly directly into rsync commands: it just needs to remember the
785    current host, directory and so on.  We can probably even do
786    completion of remote filenames.
787
788
789 RELATED PROJECTS -----------------------------------------------------
790
791 http://rsync.samba.org/rsync-and-debian/
792
793 rsyncable gzip patch
794
795   Exhaustive, tortuous testing
796
797   Cleanups?
798
799 rsyncsplit as alternative to real integration with gzip?
800
801 reverse rsync over HTTP Range
802
803   Goswin Brederlow suggested this on Debian; I think tridge and I
804   talked about it previous in relation to rproxy.