Remove TODO.md, this file is not up-to-date and also not really a good

todo list for rsync.

1 files changed, 0 insertions, 65 deletions

diff --git a/usr.bin/rsync/TODO.md b/usr.bin/rsync/TODO.md
deleted file mode 100644
index 4ba1dca3403..00000000000
--- a/usr.bin/rsync/TODO.md
+++ /dev/null
@@ -1,65 +0,0 @@
-This is a list of possible work projects within openrsync, rated by difficulty.
-
-First, porting: see
-[Porting](https://github.com/kristapsdz/openrsync/blob/master/README.md#Portability)
-for information on this topic.
-I've included the specific security porting topics below.
-
-This list also does not include adding support for features (e.g., **-u** and
-so on).  The **-a** feature is probably most important, and involves a little
-legwork in the protocol getting **-g** and **-u** passing around file modes.
-I would rate this as easy/medium.
-
-- Easy: speed up the uid/gid mapping/remapping with a simple table.
-  Right now, the code in 
-  [ids.c](https://github.com/kristapsdz/openrsync/blob/master/ids.c)
-  is simple, but could easily bottleneck with a large number of groups
-  and files with **-g**.
-
-- Easy: add a hashtable to `blk_find()` in
-  [blocks.c](https://github.com/kristapsdz/openrsync/blob/master/blocks.c)
-  for quickly looking up fast-hash matches.
-
-- Easy: print more statistics, such as transfer times and rates.
-
-- Easy: tighten the [pledge(2)](https://man.openbsd.org/pledge.2) and
-  [unveil(2)](https://man.openbsd.org/unveil.2) to work with **-n**, as
-  it does not touch files.
-
-- Easy: find the shared path for all input files and
-  [unveil(2)](https://man.openbsd.org/unveil.2) only the shared path
-  instead of each one.
-
-- Medium: have the log messages when multiplex writing (server mode) is
-  enabled by flushed out through the multiplex channel.
-  Right now, they're emitted on `stderr` just like with the client.
-
-- Medium: porting the security precautions
-  ([unveil(2)](https://man.openbsd.org/unveil.2),
-  [pledge(2)](https://man.openbsd.org/pledge.2)) to
-  [FreeBSD](https://www.freebsd.org)'s
-  [Capsicum](https://wiki.freebsd.org/Capsicum).
-  Without this in place, you're exposing your file-system to whatever is
-  coming down over the wire.
-  This is certainly possible, as openrsync makes exclusive use of the "at"
-  functions (e.g., [openat(2)](https://man.openbsd.org/openat.2)) for working
-  with files.
-
-- Hard: the same, but for Linux.
-
-- Hard: once the sender loop is optimised, the uploader can also queue
-  up block metadata to send on-demand instead of reading in the file
-  then sending, then reading again, then sending.
-
-In general, be careful with the last two.
-The rsync protocol is quite brittle and prone to deadlocking if senders
-or receivers send too much data and clog output buffers.
-So I suppose the hardest point, now that the protocol has been
-documented, is:
-
-- Hardest: make the entire system use a event-loop and loop over
-  buffered data with a fine-grained state machine.
-
-I guess that will wait for openrsync v2.
-
-Above all, `grep FIXME *.c *.h` and start from there.