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