I've gone through the CVS commit log and tried to get every
user-visible change since 2.4.6, so that we can make a proper
announcement for 2.4.7. Please let me know if anything is
missing/inaccurate.
At this stage I'm planning to release two 2.4.7pre tarballs, one with
the "large nohang patch" and one without. Some people inside VA will
be stress-testing both, and so we can see which one works out best.
It seems like most reports on this list like the patch, but I think
tridge is still conceerned that it will cause too much memory
allocation.
--
Martin
rsync 2.4.7 (sometime in 2001, maybe :)
ANNOUNCEMENTS
* Martin Pool <mbp@samba.org> is now a co-maintainer.
NEW FEATURES
* Support for LSB-compliant packaging <http://www.linuxbase.org/>
* Shell wildcards are allowed in "auth users" lines.
ENHANCEMENTS
* Include/exclude cluestick: with -vv, print out whether files are
included or excluded and why.
* Many error messages have more friendly explanations and more
details.
* Manual page improvements plus scanty protocol documentation.
* When running as --daemon in the background and using a "log
file" rsyncd.conf directive, close the log file every time it is
open when going to sleep on the socket. This allows the log
file to get cleaned out by another process.
* Change to using libpopt rather than getopt for processing
options. This makes the code cleaner and the behaviour more
consistent across platforms. popt is included and built if not
installed on the platform.
* More details in --version, including note about whether 64-bit
files, symlinks and hardlinks are supported.
* MD4 code may use less CPU cycles.
* Use mkstemp on systems where it is secure. If we use mktemp,
explain that we do it in a secure way.
* --whole-file is the default when source and target are on the
local machine.
BUG FIXES:
* Attempt to fix Large File Summit support on AIX.
* Attempt to fix error handling lockup bug.
* Give a non-0 exit code if *any* of the files we have been asked
to transfer fail to transfer
* Fix --cvs-exclude sigsegv bug.
* Applied "simple nohang patch" from Wayne Davison.
On Mon, 6 Aug 2001, Martin Pool wrote:> Please let me know if anything is missing/inaccurate.One thing that is missing is my EOF patch. Tridge apparently committed a much simpler fix for this problem that will make the new rsync client and daemon incompatible with older versions. I.e. an old rsync client connecting with a new rsync daemon would get the "@RSYNC EXIT" text output as part of the module listing, and a new rsync client accessing an older rsync server would still get the bogus EOF error at the end of the module listing. I suggest backing out the current @RSYNC EXIT changes, and applying this patch instead: http://www.clari.net/~wayne/rsync-eof.patch I have just recently tweaked it to change the "@RSYNC EOF" message that I had invented into the "@RSYNC EXIT" message that is in the current CVS.> At this stage I'm planning to release two 2.4.7pre tarballs, one with > the "large nohang patch" and one without. Some people inside VA will > be stress-testing both, and so we can see which one works out best. > It seems like most reports on this list like the patch, but I think > tridge is still concerned that it will cause too much memory > allocation.Which version are you planning to use? The one I created most recently has a fixed allocation size (1 byte per file in the transfer list): http://www.clari.net/~wayne/rsync-nohang2.patch The older patch has a little simpler logic, but it uses a potentially expanding buffer: http://www.clari.net/~wayne/rsync-nohang.patch Also, I've never gotten any feedback on my move-files patch, so I assume the plan is to just leave it out for now? ..wayne..
On Mon, 6 Aug 2001 rsync-request@lists.samba.org wrote:> To subscribe or unsubscribe via the World Wide Web, visit > http://lists.samba.org/mailman/listinfo/rsync > > Today's Topics: > > 1. rsync-2.4.7 NEWS file (Martin Pool)Martin Pool <mbp@valinux.company> wrote:> > I've gone through the CVS commit log and tried to get every > user-visible change since 2.4.6, so that we can make a proper > announcement for 2.4.7. Please let me know if anything is > missing/inaccurate. > > At this stage I'm planning to release two 2.4.7pre tarballs, one with > the "large nohang patch" and one without. Some people inside VA will > be stress-testing both, and so we can see which one works out best. > It seems like most reports on this list like the patch, but I think > tridge is still conceerned that it will cause too much memory > allocation.I look forward to seeing the "pre" tarballs. I am starting to port RSYNC to OpenVMS, and with 2.4.6 there are a number of issues that it would help me if they were fixed. Because of being a bit internet impaired, I can not supply diff files until tomorrow, and I am going from my memory, and it may be better if I apply my changes to 2.4.7pre instead. I currently have the source code (with some patches) compiling cleanly with the Compaq C compiler in a -WALL mode. The first issue that comes up is that at this time, I can not support hardlinks. Some of the code will not honor the config.h's settings on this, and will compile in references to other routines that are not compiled as they are honoring config.h. This would lead me to beleive it is a bug. I also do not have the UNIX SYSLOG API. The SYSLOG checks also continue to expect some of the SYSLOG definitions to be present even when CONFIG.H says otherwise. Compaq C will not compile code where a function prototype of a standard library call is placed in the code that is not type compatable with the standard headers that were previously #included. This compiler is common to OpenVMS, Tru-64, and LINUX on Alpha. The Compaq C compiler on OpenVMS by default has char as a signed type. The rsync code seems to be generally assuming that char is unsigned. The compiler will flag a type mismatch when attempting to pass an (unsigned char) to a (char) procedure parameter or assignment. On examining the code where these were flagged, it appears that a number of char arrays where really being used as unsinged char arrays. Several of the prototypes of functions with no parameters were missing the (void) tag. A few cases, most notably the return from a strlen() call, the code is testing to see if it is greater than 0. As the size_t type is unsigned, it is not possible for this value to be less than 0, so the compiler is concerned that (unsinged > 0) might fail to detect a routine that returns a negative value cast to an unsigned value. A change to (unsigned != 0) clarifies this. The compiler generates the same output code in either case, but the second expression makes it clear that the only real test is for non-zero. The Compaq C compiler is also flaging all #if statements that reference an undefined macro symbol in their line. There are two OpenVMS issues for compiling. One is that my build environment is using a search list, to keep my VMS specific patched files separate from a read only directory tree containing the UNIX rsync source. Once consequence of this is that the compiler can not handle include files of the type "..\foo.h". I can deal with "foo.h" and tell the compiler where find the files, or I can use "zlib\foo.h" and tell the compiler where zlib is. The other is more tricky, as those of you that have read my posts on the SAMBA technical list have seen, OpenVMS has a 48 bit inode. Since at the time C was introduced to OpenVMS, only 32 bit integers were available, this inode was represented in the struct stat as unsigned short st_ino[3]. As a result all assignments and comparisons for inodes must be done through memcpy() and memcmp(). I have worked out macros that should resolve to memcpy() and memcmp() on OpenVMS, but resolve to normal code on UNIX platforms. I do not know of any other platform with an inode type that can be larger than the largest integer value on the platform. All of these patches that I have made to 2.4.6 were done from editor scripts, so I should be able to unpack 2.4.7pre and quickly see how that build gos. I still do not have a runable executable, as I have to deal with converting the forked process to an OpenVMS AST thread, and a few other issues with file formats. So this means that for execution purposes, my patches are untested.> rsync 2.4.7 (sometime in 2001, maybe :) > > * Change to using libpopt rather than getopt for processing > options. This makes the code cleaner and the behaviour more > consistent across platforms. popt is included and built if not > installed on the platform.Note, I have a modified gnu getopt() that handles commands in a more OpenVMS friendly format. I will have to see if this is a step backwards for me. The basic differences are that OpenVMS users are used to using "/" where the gnu code uses "--", and that "foo=value" can be also specified as "foo:value". I also have some Compaq OpenVMS specific issues to resolve: 1. I see references to uid and gid's of -1, and -2. Are these flags the program, or do they map to a specific special UNIX user or group? 2. OpenVMS has a variety of internal file formats. It can send out the formats commonly used for text and binary files in a format that UNIX can use them. When receiving an update to an existing file I think I can find a way to make sure that the orignal internal file format is used. However, this conversion process is lossy. The format information is lost. Also some of the OpenVMS file types are unsuable if this format information is lost. The types that are unusable would not normally be readable on a non-OpenVMS host. It is for when two OpenVMS hosts are using RSYNC, I need to be able to identify this, so that I can send that information to the receiver. This would allow rsync to be fully functional between two OpenVMS systems. For files that are obviously not text files, and therefore not portable between operating systems, I was going to append the file format information to the end of the file name, with some character (not yet chosen) to indicate a delimiter. When copied to a non-OpenVMS system, they would have a funny name, but if that RSYNC server then served them to another OpenVMS machine, it would then be able to correctly open the file. If someone has suggestions for a character to delimit the file from it's OpenVMS attributes, I am interested. I am leaning toward the exclamation mark as it is a comment flag to the OpenVMS shell. If there are other suggestions on how a file server can give what hints it knows about the use of a file it is serving on a portable nature, I am also interested. There may be other issues I come up with as well. The OpenVMS file system does the wildcard expansion, not the shell. This changes the efficiencies of some algorthms. -John wb8tyw@qsl.network Personal Opinion Only.
> Please let me know if anything is missing/inaccurate.IRIX 6.5.12f / MIPSpro Compilers 7.3.1.2m rsync-2.4.7pre1 dumps a core file if the --daemon option is used in conjunction with the --address option. (1) ./rsync-2.4.7pre1/rsync --daemon --address 192.168.0.1 Segmentation violation dbx version 2.8.2 Mar 8 2001 01:39:27 Core from signal SIGSEGV: Segmentation violation (dbx) where> 0 strlen(0x0, 0x100488b0, 0x10021984, 0x7fff2e40, 0x73, 0x6c, 0x4c, 0x1) ["/xlv51/6.5.12f/work/irix/lib/libc/libc_n32_M4/strings/strlen.s":58, 0xfac9980]1 dopr(0x0, 0x400, 0x10021984, 0x0, 0x2, 0x0, 0x0, 0x1001beb4) ["/a/rsync-2.4.7pre1/lib/snprintf.c":337, 0x10021d10] 2 vsnprintf(0x0, 0x100488b0, 0x10021984, 0x7fff2e40, 0x2, 0x0, 0x0, 0x1001beb4) ["/a/rsync-2.4.7pre1/lib/snprintf.c":754, 0x10022958] 3 rprintf(0x0, 0x100478a0, 0x0, 0x0, 0x2, 0x0, 0x0, 0x1001beb4) ["/a/rsync-2.4.7pre1/log.c":289, 0x10011ec0] 4 ip_address(0x0, 0x100488b0, 0x10021984, 0x7fff2e40, 0x2, 0x0, 0x0, 0x1001beb4) ["/a/rsync-2.4.7pre1/socket.c":547, 0x1001bf30] 5 parse_arguments(0x7fff2ef4, 0x7fff2efc, 0x0, 0x7fff2e40, 0x2, 0x0, 0x0, 0x1001beb4) ["/a/rsync-2.4.7pre1/options.c":465, 0x10014070] 6 main(0x4, 0x7fff2f14, 0x10021984, 0x7fff2e40, 0x2, 0x0, 0x0, 0x1001beb4) ["/a/rsync-2.4.7pre1/main.c":736, 0x1000faf0] 7 __start() ["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M3/csu/crt1text.s":177, 0x100070b4]> ...(2) ./rsync-2.4.7pre1/rsync --daemon OK (3) ./rsync-2.4.6/rsync --daemon --address 192.168.0.1 ./rsync-2.4.6/rsync --daemon OK -- Ayamura KIKUCHI, M.D.
On 7 Aug 2001, Scott Howard <scott@doc.net.au> wrote:> Martin, > > There's a patch at http://rsync.samba.org/cgi-bin/rsync/incoming?id=2858 > which I sent in some time ago - any chance of getting this into 2.4.7?Not a bad feature idea. Would be better if it was documented :-), but I can do that. Is --backup-only-deleted a better option name? I think it's more obvious. -- Martin
Martin Pool
2001-Aug-15 15:10 UTC
--address broken in rsync (was Re: rsync-2.4.7 NEWS file)
On 7 Aug 2001, Ayamura KIKUCHI <ayamura@ayamura.org> wrote:> > Please let me know if anything is missing/inaccurate. > > IRIX 6.5.12f / MIPSpro Compilers 7.3.1.2m > > rsync-2.4.7pre1 dumps a core file if the --daemon option is used > in conjunction with the --address option.Thankyou for reporting this bug. We believe it is fixed in CVS and should work properly in the next tarball release. -- Martin