Proposal that we now create two branches - 2_5 and head
craig at atheros.com
Wed Jan 29 18:22:14 EST 2003
> I have several patches that I'm planning to check in soon (I'm waiting
> to see if we have any post-release tweaking to and/or branching to do).
> This list is off the top of my head, but I think it is complete:
And I have several things I would like to work on and submit:
- Fix the MD4 block and file checksums to comply with the rfc
(currently MD4 is wrong for blocks of size 64*n, or files
longer than 512MB).
- Adaptive first pass checksum lengths: use 3 or more bytes of the MD4
block checksum for big files (instead of 2). This is to avoid almost
certain first pass failures on very large files. (The block-size is
already adaptive, increasing up to 16K for large files.)
- Resubmit my --fixed-checksum-seed patch for consideration for 2.6.x.
- Resubmit my buffering/performance patch for consideration for 2.6.x.
- For --hard-links it is only necessary to send <dev,inode> for files
that have at least 2 links. Currently <dev,inode> is sent for
every file when the file list is sent. In a typical *nix file
system only a very small percentage of files have at least 2
links. Unfortunately all the bits in the flag byte are used,
so another flag byte (to indicate whether <dev,inode> is
present) would be necessary with --hard-links (unless someone
has a better idea). This would save sending up to 7 bytes
per file (or actually as many as 23 bytes per file for 64 bit
Except for the last, all these items were discussed in this group over
the last few months. The first two items and last item require a bump
in the protocol number, so I would like to include all of them together.
But before I work on these I would like to make sure there is interest
in including them.
More information about the rsync