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.
+
File attributes
Device major/minor numbers should be at least 32 bits each. See
can end up with many empty directories. We might avoid this by
lazily creating such directories.
+
zlib
- Perhaps don't use our own zlib. Will we actually be incompatible,
- or just be slightly less efficient?
+ 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.
+
logging
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.
+Better statistics:
+
+ <Rasmus> mbp: 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> Rasmus: nice idea
+ <mbp> there is --stats
+ <mbp> but at the moment it's very tridge-oriented
+ <mbp> rather than user-friendly
+ <mbp> it would be nice to improve it
+ <mbp> that would also work well with --dryrun
+
+TDB:
+
+ 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.
+
+
+chmod:
+
+ 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.
+
+
PLATFORMS ------------------------------------------------------------
Win32
we are correct to call close(), because shutdown() discards
untransmitted data.
+DEVELOPMENT ----------------------------------------------------------
+
+Splint
+
+ 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.
+
+Torture test
+
+ Something that just keeps running rsync continuously over a data set
+ likely to generate problems.
+
+Cross-testing
+
+ Run current rsync versions against significant past releases.
+
+Memory debugger
+
+ jra recommends Valgrind:
+
+ http://devel-home.kde.org/~sewardj/
+
DOCUMENTATION --------------------------------------------------------
Update README
fairly directly into rsync commands: it just needs to remember the
current host, directory and so on. We can probably even do
completion of remote filenames.
-
-%K%