Remove a couple items I know are no longer needed.
[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 too 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
317
318 Handling IPv6 on old machines
319
320   The KAME IPv6 patch is nice in theory but has proved a bit of a
321   nightmare in practice.  The basic idea of their patch is that rsync
322   is rewritten to use the new getaddrinfo()/getnameinfo() interface,
323   rather than gethostbyname()/gethostbyaddr() as in rsync 2.4.6.
324   Systems that don't have the new interface are handled by providing
325   our own implementation in lib/, which is selectively linked in.
326
327   The problem with this is that it is really hard to get right on
328   platforms that have a half-working implementation, so redefining
329   these functions clashes with system headers, and leaving them out
330   breaks.  This affects at least OSF/1, RedHat 5, and Cobalt, which
331   are moderately improtant.
332
333   Perhaps the simplest solution would be to have two different files
334   implementing the same interface, and choose either the new or the
335   old API.  This is probably necessary for systems that e.g. have
336   IPv6, but gethostbyaddr() can't handle it.  The Linux manpage claims
337   this is currently the case.
338
339   In fact, our internal sockets interface (things like
340   open_socket_out(), etc) is much narrower than the getaddrinfo()
341   interface, and so probably simpler to get right.  In addition, the
342   old code is known to work well on old machines.
343
344   We could drop the rather large lib/getaddrinfo files.
345
346
347 Other IPv6 stuff:
348   
349   Implement suggestions from http://www.kame.net/newsletter/19980604/
350   and ftp://ftp.iij.ad.jp/pub/RFC/rfc2553.txt
351
352   If a host has multiple addresses, then listen try to connect to all
353   in order until we get through.  (getaddrinfo may return multiple
354   addresses.)  This is kind of implemented already.
355
356   Possibly also when starting as a server we may need to listen on
357   multiple passive addresses.  This might be a bit harder, because we
358   may need to select on all of them.  Hm.
359
360   Define a syntax for IPv6 literal addresses.  Since they include
361   colons, they tend to break most naming systems, including ours.
362   Based on the HTTP IPv6 syntax, I think we should use
363  
364      rsync://[::1]/foo/bar
365      [::1]::bar
366
367   which should just take a small change to the parser code.
368
369
370 Errors
371
372   If we hang or get SIGINT, then explain where we were up to.  Perhaps
373   have a static buffer that contains the current function name, or
374   some kind of description of what we were trying to do.  This is a
375   little easier on people than needing to run strace/truss.
376
377   "The dungeon collapses!  You are killed."  Rather than "unexpected
378   eof" give a message that is more detailed if possible and also more
379   helpful.  
380
381   If we get an error writing to a socket, then we should perhaps
382   continue trying to read to see if an error message comes across
383   explaining why the socket is closed.  I'm not sure if this would
384   work, but it would certainly make our messages more helpful.
385
386   What happens if a directory is missing -x attributes.  Do we lose
387   our load?  (Debian #28416)  Probably fixed now, but a test case
388   would be good.
389
390
391 File attributes
392
393   Device major/minor numbers should be at least 32 bits each.  See
394   http://lists.samba.org/pipermail/rsync/2001-November/005357.html
395
396   Transfer ACLs.  Need to think of a standard representation.
397   Probably better not to even try to convert between NT and POSIX.
398   Possibly can share some code with Samba.
399
400 Empty directories
401
402   With the current common --include '*/' --exclude '*' pattern, people
403   can end up with many empty directories.  We might avoid this by
404   lazily creating such directories.
405
406
407 zlib
408
409   Perhaps don't use our own zlib.  
410
411   Advantages:
412    
413     - will automatically be up to date with bugfixes in zlib
414
415     - can leave it out for small rsync on e.g. recovery disks
416
417     - can use a shared library
418
419     - avoids people breaking rsync by trying to do this themselves and
420       messing up
421
422   Should we ship zlib for systems that don't have it, or require
423   people to install it separately?
424
425   Apparently this will make us incompatible with versions of rsync
426   that use the patched version of rsync.  Probably the simplest way to
427   do this is to just disable gzip (with a warning) when talking to old
428   versions.
429
430
431 logging
432
433   Perhaps flush stdout after each filename, so that people trying to
434   monitor progress in a log file can do so more easily.  See
435   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=48108
436
437   At the connections that just get a list of modules are not logged,
438   but they should be.
439
440   If a child of the rsync daemon dies with a signal, we should notice
441   that when we reap it and log a message.
442
443   Keep stderr and stdout properly separated (Debian #23626)
444
445   After we get the @RSYNCD greeting from the server, we know it's
446   version but we have not yet sent the command line, so we could just
447   remove the -z option if the server is too old.  
448
449   For ssh invocation it's not so simple, because we actually use the
450   command line to start the remote process.  However, we only actually
451   do compression in token.c, and we could therefore once we discover
452   the remote version emit an error if it's too old.  I'm not sure if
453   that's a good tradeoff or not.
454
455
456 proxy authentication
457
458   Allow RSYNC_PROXY to be http://user:pass@proxy.foo:3128/, and do
459   HTTP Basic Proxy-Authentication.  
460
461   Multiple schemes are possible, up to and including the insanity that
462   is NTLM, but Basic probably covers most cases.
463
464 SOCKS
465
466   Add --with-socks, and then perhaps a command-line option to put them
467   on or off.  This might be more reliable than LD_PRELOAD hacks.
468
469 FAT support
470
471   rsync to a FAT partition on a Unix machine doesn't work very well
472   at the moment.  I think we get errors about invalid filenames and 
473   perhaps also trying to do atomic renames.
474
475   I guess the code to do this is currently #ifdef'd on Windows; perhaps
476   we ought to intelligently fall back to it on Unix too.
477
478
479 Better statistics:
480
481   <Rasmus> mbp: hey, how about an rsync option that just gives you the
482   summary without the list of files?  And perhaps gives more
483   information like the number of new files, number of changed,
484   deleted, etc. ?
485   <mbp> Rasmus: nice idea
486   <mbp> there is --stats
487   <mbp> but at the moment it's very tridge-oriented
488   <mbp> rather than user-friendly
489   <mbp> it would be nice to improve it
490   <mbp> that would also work well with --dryrun
491
492 TDB:
493
494   Rather than storing the file list in memory, store it in a TDB.
495
496   This *might* make memory usage lower while building the file list.
497
498   Hashtable lookup will mean files are not transmitted in order,
499   though... hm.
500
501   This would neatly eliminate one of the major post-fork shared data
502   structures.
503
504
505 chmod:
506
507   On 12 Mar 2002, Dave Dykstra <dwd@bell-labs.com> wrote:
508   > If we would add an option to do that functionality, I would vote for one
509   > that was more general which could mask off any set of permission bits and
510   > possibly add any set of bits.  Perhaps a chmod-like syntax if it could be
511   > implemented simply.
512
513   I think that would be good too.  For example, people uploading files   
514   to a web server might like to say
515
516   rsync -avzP --chmod a+rX ./ sourcefrog.net:/home/www/sourcefrog/
517
518   Ideally the patch would implement as many of the gnu chmod semantics
519   as possible.  I think the mode parser should be a separate function
520   that passes back something like (mask,set) description to the rest of
521   the program.  For bonus points there would be a test case for the  
522   parser.
523
524   Possibly also --chown
525
526   (Debian #23628)
527
528
529 --diff
530
531   Allow people to specify the diff command.  (Might want to use wdiff,
532   gnudiff, etc.)
533
534   Just diff the temporary file with the destination file, and delete
535   the tmp file rather than moving it into place.
536
537   Interaction with --partial.
538
539   Security interactions with daemon mode?
540
541   (Suggestion from david.e.sewell)
542
543
544 Incorrect timestamps (Debian #100295)
545
546   A bit hard to believe, but apparently it happens.
547
548
549 Check "refuse options works"
550
551   We need a test case for this...
552
553   Was this broken when we changed to popt?
554
555
556 PERFORMANCE ----------------------------------------------------------
557
558 MD4 file_sum
559
560   If we're doing a local transfer, or using -W, then perhaps don't
561   send the file checksum.  If we're doing a local transfer, then
562   calculating MD4 checksums uses 90% of CPU and is unlikely to be
563   useful.
564
565   Indeed for transfers over zlib or ssh we can also rely on the
566   transport to have quite strong protection against corruption.
567
568   Perhaps we should have an option to disable this, analogous to
569   --whole-file, although it would default to disabled.  The file
570   checksum takes up a definite space in the protocol -- we can either
571   set it to 0, or perhaps just leave it out.
572
573 MD4
574
575   Perhaps borrow an assembler MD4 from someone?
576
577   Make sure we call MD4 with properly-sized blocks whenever possible
578   to avoid copying into the residue region?
579
580 String area code
581
582   Test whether this is actually faster than just using malloc().  If
583   it's not (anymore), throw it out.
584           
585
586 PLATFORMS ------------------------------------------------------------
587
588 Win32
589
590   Don't detach, because this messes up --srvany.
591
592   http://sources.redhat.com/ml/cygwin/2001-08/msg00234.html
593
594   According to "Effective TCP/IP Programming" (??) close() on a socket
595   has incorrect behaviour on Windows -- it sends a RST packet to the
596   other side, which gives a "connection reset by peer" error.  On that
597   platform we should probably do shutdown() instead.  However, on Unix
598   we are correct to call close(), because shutdown() discards
599   untransmitted data.
600
601
602 DEVELOPMENT ----------------------------------------------------------
603
604 Splint
605
606   Build rsync with SPLINT to try to find security holes.  Add
607   annotations as necessary.  Keep track of the number of warnings
608   found initially, and see how many of them are real bugs, or real
609   security bugs.  Knowing the percentage of likely hits would be
610   really interesting for other projects.
611
612 Torture test
613
614   Something that just keeps running rsync continuously over a data set
615   likely to generate problems.
616
617 Cross-testing
618
619   Run current rsync versions against significant past releases.
620
621 Memory debugger
622
623   jra recommends Valgrind:
624
625     http://devel-home.kde.org/~sewardj/
626
627 Release script
628   
629   Update spec files
630
631   Build tar file; upload
632
633   Send announcement to mailing list and c.o.l.a.
634   
635   Make freshmeat announcement
636
637   Update web site
638
639
640
641 TESTING --------------------------------------------------------------
642
643 Cross-test versions
644
645   Part of the regression suite should be making sure that we don't
646   break backwards compatibility: old clients vs new servers and so
647   on.  Ideally we would test both up and down from the current release
648   to all old versions.
649
650   We might need to omit broken old versions, or versions in which
651   particular functionality is broken
652
653   It might be sufficient to test downloads from well-known public
654   rsync servers running different versions of rsync.  This will give
655   some testing and also be the most common case for having different
656   versions and not being able to upgrade.
657
658
659 Test on kernel source
660
661   Download all versions of kernel; unpack, sync between them.  Also
662   sync between uncompressed tarballs.  Compare directories after
663   transfer.
664
665   Use local mode; ssh; daemon; --whole-file and --no-whole-file.
666
667   Use awk to pull out the 'speedup' number for each transfer.  Make
668   sure it is >= x.
669
670
671 Test large files
672
673   Sparse and non-sparse
674
675 Mutator program
676
677   Insert bytes, delete bytes, swap blocks, ...
678
679 configure option to enable dangerous tests
680
681 If tests are skipped, say why.
682
683 Test daemon feature to disallow particular options.
684
685 Pipe program that makes slow/jerky connections.
686
687 Versions of read() and write() that corrupt the stream, or abruptly fail
688
689 Separate makefile target to run rough tests -- or perhaps just run
690 them every time?
691
692 Test "refuse options" works
693
694   What about for --recursive?
695
696   If you specify an unrecognized option here, you should get an error.
697
698
699 DOCUMENTATION --------------------------------------------------------
700
701 Update README
702
703 Keep list of open issues and todos on the web site
704
705 Update web site from CVS
706
707
708 Perhaps redo manual as SGML
709
710   The man page is getting rather large, and there is more information
711   that ought to be added.
712
713   TexInfo source is probably a dying format.
714
715   Linuxdoc looks like the most likely contender.  I know DocBook is
716   favoured by some people, but it's so bloody verbose, even with emacs
717   support.
718
719
720 BUILD FARM -----------------------------------------------------------
721
722 Add machines
723
724   Cygwin (on different versions of Win32?)
725
726   HP-UX variants (via HP?)
727
728   SCO
729
730
731 LOGGING --------------------------------------------------------------
732
733   Perhaps flush stdout after each filename, so that people trying to
734   monitor progress in a log file can do so more easily.  See
735   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=48108
736
737   At the connections that just get a list of modules are not logged,
738   but they should be.
739
740   If a child of the rsync daemon dies with a signal, we should notice
741   that when we reap it and log a message.
742
743   Keep stderr and stdout properly separated (Debian #23626)
744
745   Use a separate function for reporting errors; prefix it with
746   "rsync:" or "rsync(remote)", or perhaps even "rsync(local
747   generator): ".
748
749 verbose output
750   
751   Indicate whether files are new, updated, or deleted
752
753   At end of transfer, show how many files were or were not transferred
754   correctly.
755
756 -vv
757
758   Explain *why* every file is transferred or not (e.g. "local mtime
759   123123 newer than 1283198")
760
761
762 debugging of daemon
763
764   Add an rsyncd.conf parameter to turn on debugging on the server.
765
766
767
768 NICE -----------------------------------------------------------------
769
770 --no-detach and --no-fork options
771
772   Very useful for debugging.  Also good when running under a
773   daemon-monitoring process that tries to restart the service when the
774   parent exits.
775
776 hang/timeout friendliness
777
778 internationalization
779
780   Change to using gettext().  Probably need to ship this for platforms
781   that don't have it.  
782
783   Solicit translations.
784
785   Does anyone care?  Before we bother modifying the code, we ought to
786   get the manual translated first, because that's possibly more useful
787   and at any rate demonstrates desire.
788
789 rsyncsh 
790
791    Write a small emulation of interactive ftp as a Pythonn program
792    that calls rsync.  Commands such as "cd", "ls", "ls *.c" etc map
793    fairly directly into rsync commands: it just needs to remember the
794    current host, directory and so on.  We can probably even do
795    completion of remote filenames.
796
797
798 RELATED PROJECTS -----------------------------------------------------
799
800 http://rsync.samba.org/rsync-and-debian/
801
802 rsyncable gzip patch
803
804   Exhaustive, tortuous testing
805
806   Cleanups?
807
808 rsyncsplit as alternative to real integration with gzip?
809
810 reverse rsync over HTTP Range
811
812   Goswin Brederlow suggested this on Debian; I think tridge and I
813   talked about it previous in relation to rproxy.