Try Understand Error
I'm using server on OpenBSD 3.4 to backuping data from remote server via rsync.On backup server I am install rsync-2.5.6 and on remote machine rsync-2.5.7 (RedHat 8.0) . For backuping data I'm using the following command : rsync -av -e ssh [EMAIL PROTECTED]:/var/backup/ALL-15-Mar.tar /var/backup/3 This command copy file ALL-15-Mar.tar from host log(RedHat box) to local directory on OpenBSD. The I'm execute thos command I see the same error: mkstemp .ALL-15-Mar.tar.T30894 failed: Permission denied rsync error: some files could not be transferred (code 23) at /usr/obj/i386/rsync-2.5.6/rsync-2.5.6/main.c(1045) What I'm doing incorrectly ? What does this error mean? The permissions on log is following : [EMAIL PROTECTED] backup]# ls -la total 848000 drwxr-xr-x2 root root 4096 Mar 15 14:01 . drwxr-xr-x 34 root root 4096 Mar 10 14:19 .. -rwxr-xr-x1 backup backup 867491840 Mar 15 01:31 ALL-15-Mar.tar -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
rsyncd without syslog
Hi, is it possible to use the rsyncd Daemon without any logging. I would like to make a network synchronization on a specific directory in a small network (10 Hosts) . These synchronisation should happen every 10 secounds. My logfile increases to fast with the logging option therefore it is better to use rsync without any logging. Thanks for answering. Please apologize my bad english. I hope you know what I mean. -- Torsten Senf -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
'Invalid cross-device link' message on sparc
Hi, I've got problems with a symlink to another device in a directory used with '--link-dest'. I've got something like [EMAIL PROTECTED]:/tmp/rsync% ls -alR .: total 16 drwxr-xr-x4 augustin augustin 4096 Mar 15 12:07 ./ drwxrwxrwt4 root root 4096 Mar 15 10:56 ../ drwxr-xr-x3 augustin augustin 4096 Mar 11 15:05 source/ drwxr-xr-x2 augustin augustin 4096 Mar 11 15:06 unusable_link-dest/ ./source: total 12 drwxr-xr-x3 augustin augustin 4096 Mar 11 15:05 ./ drwxr-xr-x4 augustin augustin 4096 Mar 15 12:07 ../ drwxr-xr-x2 augustin augustin 4096 Mar 11 15:05 dir/ ./source/dir: total 12 drwxr-xr-x2 augustin augustin 4096 Mar 11 15:05 ./ drwxr-xr-x3 augustin augustin 4096 Mar 11 15:05 ../ -rw-r--r--1 augustin augustin9 Mar 11 12:17 foo ./unusable_link-dest: total 8 drwxr-xr-x2 augustin augustin 4096 Mar 11 15:06 ./ drwxr-xr-x4 augustin augustin 4096 Mar 15 12:07 ../ lrwxrwxrwx1 augustin augustin 19 Mar 11 15:06 dir - /home2/augustin/dir/ and [EMAIL PROTECTED]:/tmp/rsync% ls -alR /home2/augustin/dir /home2/augustin/dir: total 20 drwxr-xr-x2 augustin augustin 4096 Mar 11 12:07 ./ drwxr-xr-x 229 augustin liinstud12288 Mar 15 12:06 ../ -rw-r--r--1 augustin augustin9 Mar 11 12:17 foo and when I try: e/ dest building file list ... done created directory dest ./ dir/ link /tmp/rsync/unusable_link-dest/dir/foo = dir/foo : Invalid cross-device link wrote 106 bytes read 20 bytes 252.00 bytes/sec total size is 9 speedup is 0.07 I get: [EMAIL PROTECTED]:/tmp/rsync% ls -alR dest dest: total 12 drwxr-xr-x3 augustin augustin 4096 Mar 11 15:05 ./ drwxr-xr-x5 augustin augustin 4096 Mar 15 12:10 ../ drwxr-xr-x2 augustin augustin 4096 Mar 11 15:05 dir/ dest/dir: total 8 drwxr-xr-x2 augustin augustin 4096 Mar 11 15:05 ./ drwxr-xr-x3 augustin augustin 4096 Mar 11 15:05 ../ I've tested this with rsync-HEAD-20040311-1010GMT.tar.gz (no special configure options) using Solaris 2.7 and Debian Woody on a UltraSparc I box. Everything is fine using Debian on i386. Perhaps something with 32/64 bit? Linux-Kernel is 64bit the libraries used are 32bit: [EMAIL PROTECTED]:/tmp/rsync% ldd /usr/local/rsync-20040311/bin/rsync libpopt.so.0 = /lib/libpopt.so.0 (0x7002c000) libresolv.so.2 = /lib/libresolv.so.2 (0x70044000) libc.so.6 = /lib/libc.so.6 (0x70064000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x7000) /tmp is on a SCSI hard disk. Any hints, any ideas what might go wrong? Btw. I had a look at the code in generator.c. Wouldn't it be a good idea to report a critical error and not only a message in verbose mode if do_link fails? bye, Werner Augustin -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: 'Invalid cross-device link' message on sparc
Werner Augustin [EMAIL PROTECTED] writes: and when I try: e/ dest building file list ... done created directory dest ./ dir/ link /tmp/rsync/unusable_link-dest/dir/foo = dir/foo : Invalid cross-device link wrote 106 bytes read 20 bytes 252.00 bytes/sec total size is 9 speedup is 0.07 Oops, something went wrong when I copied this, actually I tried: [EMAIL PROTECTED]:/tmp/rsync% /usr/local/rsync-20040311/bin/rsync -a -v --link-dest=/tmp/rsync/unusable_link-dest source/ dest building file list ... done created directory dest ./ dir/ link /tmp/rsync/unusable_link-dest/dir/foo = dir/foo : Invalid cross-device link wrote 106 bytes read 20 bytes 252.00 bytes/sec total size is 9 speedup is 0.07 bye, Werner Augustin -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: 'Invalid cross-device link' message on sparc
tmp/rsync/unusable_link-dest/dir/foo and dir/foo are on different filesystems. --link-dest= makes hard links - new directory entries pointing at the same inodes. Directory entries don't have any way to specify the device containing the filesystem. It's assumed that it's the same device containing the directory. symlinks can span devices, but they don't maintain a link count on the file, so deleting the original link takes the link count to 0 and frees the data, and also leaves the symlink as a broken link. If you want to use --link-dest, you will have to point to a place on the same filesystem containing the stuff you're linking. --link-dest=DIR create hardlinks to DIR for unchanged files Tim Conway Unix System Administration Contractor - IBM Global Services [EMAIL PROTECTED] [EMAIL PROTECTED]:/tmp/rsync% /usr/local/rsync-20040311/bin/rsync -a -v --link-dest=/tmp/rsync/unusable_link-dest source/ dest building file list ... done created directory dest ./ dir/ link /tmp/rsync/unusable_link-dest/dir/foo = dir/foo : Invalid cross-device link -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync wont work
There we are. Thanks. OK, you're using ssh, and you can ssh in, so we can assume you're getting in. Now, ssh [EMAIL PROTECTED] and then which rsync is different from ssh [EMAIL PROTECTED] which rsync. ssh without a command starts a login shell, and you get your full environment. With a command, you get a very stripped-down environment, which is unlikely to have /usr/local/bin in the path. I can state with near unity certainty that rsync -vvvcrlpogtz --rsync-path=/usr/local/bin/rsync /tmp/ [EMAIL PROTECTED]:/tmp will work. Alternately, you could modify your system initialization scripts to get /usr/local/bin in your basic path, or symlink /usr/local/bin/rsync into /bin or /usr/bin. I generally leave the system unmodified, and change my cmdline, but if you're setting up something for newbies to do their own commandlines, you'll probably end up making it idiot-proof. Oh, and you didn't get the email directly because your system wanted me to authenticate myself. I declined to make the effort. I figured you could just read the copy from the list. Good luck, Tim Conway Unix System Administration Contractor - IBM Global Services [EMAIL PROTECTED] -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: suppressing motd without decreasing verbosity
The simplest solution is to not have the rsyncd demand that clients display the motd. motd is not considered part of verbosity, so the only way to shut it off on the client side is to have the client shut all the way up. +++ [EMAIL PROTECTED] /home/cnwt99man rsyncd.conf |grep -C 2 motd file motd file The motd file option allows you to specify a message of the day to display to clients on each connect. This usually con- tains site information and any legal notices. The default is no motd file. [EMAIL PROTECTED] /home/cnwt99 +++ Short of that, I'm stumped. Tim Conway Unix System Administration Contractor - IBM Global Services [EMAIL PROTECTED] Is there a way to make the rsync client suppress the motd without suppressing other messages when connecting to an rsync server? What I want is to run rsync from cron and have it produce output only when any files have been downloaded or deleted and whenever errors have happened. Otherwise, I want it to be quiet. This doesn't seem to be possible with rsync as of version 2.5.7. When I use the -v option, the motd and file transfers are printed. With either -q or -vq, nothing is printed. When I don't use any of those options, then motd is printed but file transfer is not reported. There doesn't seem to exist an option for reporting file transfers only, or is there something I am missing? -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsyncd without syslog
First, good luck with your dynamic data... it sounds like you might be wanting a distributed filesystem instead, but on to the question: In your rsyncd.conf log file = /dev/null That stops sending to syslog, and throws away the log data (rather than storing it in a file). Oh, and if you hadn't apologized, nobody would have guessed that you weren't a native speaker of English. Tim Conway Unix System Administration Contractor - IBM Global Services [EMAIL PROTECTED] Hi, is it possible to use the rsyncd Daemon without any logging. I would like to make a network synchronization on a specific directory in a small network (10 Hosts) . These synchronisation should happen every 10 secounds. My logfile increases to fast with the logging option therefore it is better to use rsync without any logging. Thanks for answering. Please apologize my bad english. I hope you know what I mean. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: MD4 checksum_seed
Hi, On 2004/03/15 03:49, Donovan Baarda wrote: Note that, above, block hash collisions are very easy to find if you know checksum_seed. The rolling Fletcher checksum1 is trivially defeated. To defeat the k-bit truncated MD4 checksum2, just keep generate random blocks having the same checksum1 until you find two with the same checksum2; by the birthday paradox it will take about 2^(k/2) attempts, where usually k=16 or k=24 with J.W. Schultz's code. I haven't really thought much about carefully crafted data to bust things. I didn't think the Fletcher checksum was that bad. Although I can see that it would be fairly trivial to craft data for collisions, wouldn't it be harder to craft data for a Fletcher collision _and_ attempt to produce a checksum2 collision? For blocks larger than about 270 bytes, the strength added by the Fletcher sum is close to zero -- you can obtain any Fletcher sum of your choice, with plenty of easily manipulated degrees of freedom remaining. Smaller blocks are a bit messier (e.g., for blocksize=256 you can't obtain all possibilities of the lower 16 bit of the Fletcher sum), but still doable. So you can sample sufficiently random blocks all having the same Fletcher sum (say, zero), and then the birthday paradox applies to strong sum without any special trickery. Just to be sure, I wrote a quickdirty collision search code for the rsync and librsync hashes. I used a generic collision-finding algorithm (namely Gabriel Nivasch's multistack variant of the generalized Rho method) to search for a truncated MD4 collision among the blocks whose Fletcher sum is zero. It took 13ms to find a collision for the default parameters of rsync version2.6.0, with either checksum_seed=0 (disabled) or checksum_seed=32761 (the value fixed for batch mode). With a 4 byte strong hash, which is the most you're likely to see with Schultz's code, the above took 1.4 seconds. For librsync with default parameters (8-byte strong hash), finding a collision took a couple of hours. Here are examples of colliding pairs for each of the above case: http://dl.tromer.org/misc/rsync-collisions.tgz I should stress that if you manage to insert such a pair into someone's file, his rsyncs will become slow and his rdiffs will silently fail. Such poisoning is very practical in many settings -- consider website databases and user mailboxes (yes, a pure-ASCII collision can be easily generated with a bit of extra effort). Of course, the attacker will need some knowledge about the file format, and some care in regard to alignment and timing. Still, not a pretty prospect. The 2^(k/2) attempts assumes random attempts... how does this compare to crafted to bust fletcher attempts? Very favorably. My code performs just as one would expect for a random function. As you mentioned, MD4 has known weaknesses [1]; I'm not sure it's easy to exploit them in our context, but the Fletcher checksum may indeed make it somewhat harder to do so. Anyway, I didn't take advantage of them. Does checksum_seed really need to be random for the checksum2 to be random? I know md4 is considered vulnerable compared to md5, but does it have a poor distribution for a fixed seed? If it does, would it make sense to switch to md5 rather than randomise the seed? checksum_seed must be random for the checksum2 to be random -- simply, because there is no other source of randomness in the hash calculation, and if everything is deterministic then you can find collisions in advance and put them in the data. This doesn't have anything to do with the cryptographic strength of MD4. But if the attacks of [1] can be adapted to our scenario then things will become even *worse* than the above, and this is a good reason to switch to MD5. For the purpose of evaluating the probability of retransmission, rsync uses s2length bytes of good hash plus 4 bytes of wishful thinking, and Baarda's analysis doesn't really apply. You can still use the same formula, just don't count checksum1 in the checksum size part of it. Or depending on how much you think it's worth you could count it as x32 bits worth of checksum, not the full 32 bits. In adversarial setting the Fletcher checksum is worthless. So to obtain the intended 2^-10 failure probability, rsync should increase its strong checksum by 4 bytes. That's for rsync in normal mode, where checksum_seed is randomized. For fixed checksum_seed (i.e., rsync in batch mode and librsync) the failure probability in adversarial setting is 1, as demonstrated above. A couple of related notes: librsync really ought to include a whole-file hash, like rsync. Maybe also an option of retransmitting the file in case of failure (where possible). Either way, failure must be reliably detected. Beside increasing reliability, in many cases it would allow use of smaller block checksums. You can't just entrust integrity checking to a subsequent invocation of md5sum or such; re-reading the files is expensive and not always
Re: suppressing motd without decreasing verbosity
Yes, that's a possibility but unfortunately, I don't have control of the remote site. I am surprised there is no way to to do this with the client. -akop On Mon, Mar 15, 2004 at 08:04:47AM -0700, Tim Conway wrote: The simplest solution is to not have the rsyncd demand that clients display the motd. motd is not considered part of verbosity, so the only way to shut it off on the client side is to have the client shut all the way up. +++ [EMAIL PROTECTED] /home/cnwt99man rsyncd.conf |grep -C 2 motd file motd file The motd file option allows you to specify a message of the day to display to clients on each connect. This usually con- tains site information and any legal notices. The default is no motd file. [EMAIL PROTECTED] /home/cnwt99 +++ Short of that, I'm stumped. Tim Conway Unix System Administration Contractor - IBM Global Services [EMAIL PROTECTED] Is there a way to make the rsync client suppress the motd without suppressing other messages when connecting to an rsync server? What I want is to run rsync from cron and have it produce output only when any files have been downloaded or deleted and whenever errors have happened. Otherwise, I want it to be quiet. This doesn't seem to be possible with rsync as of version 2.5.7. When I use the -v option, the motd and file transfers are printed. With either -q or -vq, nothing is printed. When I don't use any of those options, then motd is printed but file transfer is not reported. There doesn't seem to exist an option for reporting file transfers only, or is there something I am missing? -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html -- -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: [patch] Correct configure test for sin_len to compile on Tru64 Unix
wayned So, it looks like we need 2 configure tests and separate defines for wayned sa_len and sin_len. wayned How about the appended patch? This applies to the very latest CVS wayned source and would require the running of autoconf and autoheader wayned after applying it. I use rsync 2.6.1cvs on FreeBSD 4.X machines. This OS has sin_len in struct sockaddr_in. But after configure, HAVE_SOCKADDR_SIN_LEN remains undef in config.h. Needs patch like this ? Index: configure.in === RCS file: /cvsroot/rsync/configure.in,v retrieving revision 1.186 diff -u -r1.186 configure.in --- configure.in27 Feb 2004 07:22:39 - 1.186 +++ configure.in16 Mar 2004 00:51:14 - @@ -396,12 +396,13 @@ #include sys/socket.h ]) -AC_CHECK_MEMBER([struct sockaddr.sin_len], +AC_CHECK_MEMBER([struct sockaddr_in.sin_len], [ AC_DEFINE(HAVE_SOCKADDR_SIN_LEN, 1, [Do we have sockaddr.sin_len?]) ], [], [ #include sys/types.h #include sys/socket.h +#include netinet/in.h ]) AC_MSG_CHECKING(struct sockaddr_storage) -- Yes, I'm in panic. Shinichi Maruyama ([EMAIL PROTECTED]) -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: [patch] Correct configure test for sin_len to compile on Tru64 Unix
On Tue, Mar 16, 2004 at 10:01:19AM +0900, Shinichi Maruyama wrote: This OS has sin_len in struct sockaddr_in. But after configure, HAVE_SOCKADDR_SIN_LEN remains undef in config.h. Needs patch like this ? Yup -- much appreciated! I've checked in your fix, plus an extra cleanup of the define names in light of this fixed structure check. ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: MD4 checksum_seed
On Tue, 2004-03-16 at 10:44, Eran Tromer wrote: Hi, On 2004/03/15 03:49, Donovan Baarda wrote: [...] Just to be sure, I wrote a quickdirty collision search code for the rsync and librsync hashes. I used a generic collision-finding algorithm (namely Gabriel Nivasch's multistack variant of the generalized Rho method) to search for a truncated MD4 collision among the blocks whose Fletcher sum is zero. It took 13ms to find a collision for the default parameters of rsync version2.6.0, with either checksum_seed=0 (disabled) or checksum_seed=32761 (the value fixed for batch mode). With a 4 byte strong hash, which is the most you're likely to see with Schultz's code, the above took 1.4 seconds. For librsync with default parameters (8-byte strong hash), finding a collision took a couple of hours. Here are examples of colliding pairs for each of the above case: http://dl.tromer.org/misc/rsync-collisions.tgz [...] with an 8-byte hash that means you tested approximately 2^64/2 crafted fletcher busting blocks to find a collision, yeah? Did that really take only a couple of hours? Man, computers are heaps faster now! By my calculations, even processing them at one block every micro-second, that would have taken over 272 years. Are you sure? You must have got _very_ lucky, or there is some serious flaws in md4. Perhaps there is a serious problem with how we are truncating the md4? I just checked your librsync sample blocks... you are right. The first 8 bytes of md4sum are the same, the rollsums both evaluate to 0, and yet the data is different. How the hell did you do that? I glanced at Gabriel Nivasch's stuff but I can't see how it could have shortcut it so much... The 2^(k/2) attempts assumes random attempts... how does this compare to crafted to bust fletcher attempts? [...] Just noticed you use 2^(k/2), not (2^K)/2... this must be part of the reason :-) I thought that without using some sort of known vulnerability the formula would be; avg number of random attempts = number of possible sum values / 2 Which for a 64 bit sum would be (2^64)/2. I guess this assumes that the sum function when applied iteratively to itself the way Gabriel Nivasch suggests will walk through the entire sumspace before repeating. Does the reduced search space assume some sort of distribution of repeat loops in the sum algorithm? Wouldn't this be highly dependent on the checksum algorithm used? Does checksum_seed really need to be random for the checksum2 to be random? I know md4 is considered vulnerable compared to md5, but does it have a poor distribution for a fixed seed? If it does, would it make sense to switch to md5 rather than randomise the seed? checksum_seed must be random for the checksum2 to be random -- simply, because there is no other source of randomness in the hash calculation, I was actually thinking pseudo-random, as in evenly distributed, and with no exploitable pattern ie still requiring a a exhaustive search with no known shortcuts. and if everything is deterministic then you can find collisions in advance and put them in the data. This doesn't have anything to do with the cryptographic strength of MD4. But if the attacks of [1] can be adapted to our scenario then things will become even *worse* than the above, and this is a good reason to switch to MD5. [...] Hmmm. yeah. The deterministic nature of a fixed seed is a bit of a problem. You can still use the same formula, just don't count checksum1 in the checksum size part of it. Or depending on how much you think it's worth you could count it as x32 bits worth of checksum, not the full 32 bits. In adversarial setting the Fletcher checksum is worthless. So to obtain the intended 2^-10 failure probability, rsync should increase its strong checksum by 4 bytes. That's for rsync in normal mode, where checksum_seed is randomized. For fixed checksum_seed (i.e., rsync in batch mode and librsync) the failure probability in adversarial setting is 1, as demonstrated above. scary. A couple of related notes: librsync really ought to include a whole-file hash, like rsync. Maybe also an option of retransmitting the file in case of failure (where possible). Either way, failure must be reliably detected. Beside increasing reliability, in many cases it would allow use of smaller block checksums. You can't just entrust integrity checking to a subsequent invocation of md5sum or such; re-reading the files is expensive and not always possible. Yeah. I've been thinking the same for some time. Because librsync separates the signature/delta/patch operations, retransmission is an application level decision, but librsync should certainly warn you when it fails. The use of CHAR_OFFSET is a pure waste of CPU cycles. It merely amounts to adding constants to s1 and s2 (blocklen*CHAR_OFFSET and blocklen*(blocklen+1)/2*CHAR_OFFSET, respectively). These depend only on the block length, which you know
CVS update: rsync
Date: Tue Mar 16 01:26:28 2004 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv9446 Modified Files: configure config.h.in Log Message: Regenerated. Revisions: configure 1.178 = 1.179 http://www.samba.org/cgi-bin/cvsweb/rsync/configure.diff?r1=1.178r2=1.179 config.h.in 1.86 = 1.87 http://www.samba.org/cgi-bin/cvsweb/rsync/config.h.in.diff?r1=1.86r2=1.87 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Tue Mar 16 01:26:31 2004 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv9462 Modified Files: clientname.c socket.c Log Message: Changed HAVE_SOCKADDR_SIN_LEN to HAVE_SOCKADDR_IN_LEN. Revisions: clientname.c1.16 = 1.17 http://www.samba.org/cgi-bin/cvsweb/rsync/clientname.c.diff?r1=1.16r2=1.17 socket.c1.93 = 1.94 http://www.samba.org/cgi-bin/cvsweb/rsync/socket.c.diff?r1=1.93r2=1.94 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync/lib
Date: Tue Mar 16 01:26:36 2004 Author: wayned Update of /data/cvs/rsync/lib In directory dp.samba.org:/tmp/cvs-serv9479/lib Modified Files: getaddrinfo.c getnameinfo.c Log Message: Changed HAVE_SOCKADDR_SA_LEN to HAVE_SOCKADDR_LEN. Revisions: getaddrinfo.c 1.19 = 1.20 http://www.samba.org/cgi-bin/cvsweb/rsync/lib/getaddrinfo.c.diff?r1=1.19r2=1.20 getnameinfo.c 1.12 = 1.13 http://www.samba.org/cgi-bin/cvsweb/rsync/lib/getnameinfo.c.diff?r1=1.12r2=1.13 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Tue Mar 16 01:26:40 2004 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv9542 Modified Files: configure.in Log Message: Fixed the test for sin_len as noted by Shinichi Maruyama. Changed the define name generated for this test and the sa_len test. Revisions: configure.in1.186 = 1.187 http://www.samba.org/cgi-bin/cvsweb/rsync/configure.in.diff?r1=1.186r2=1.187 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
