Re: rsyncing devices
On Sun, Dec 02, 2001 at 04:14:15PM +1100, Martin Pool wrote: On 27 Nov 2001, Dave Dykstra [EMAIL PROTECTED] wrote: I can reproduce it, and I think you've stumbled on a significant bug. The problem is that rsync always assumes stat variable st_rdev, which contains both the major and minor number, is always 4 bytes and is always the same format on both sides. On the rsync I tried on Linux, it is 8 bytes, whereas it was 4 bytes on Solaris. I assume it depends on whether or not 64 bit mode gets enabled on the operating system version you're on. Are the top bits actually used? Perhaps truncation would be marginally better, or perhaps we should have a ./configure warning that this will be broken if sizeof(st_rdev)4? I don't think we can assume that they're not used, although yes truncation would be marginally better and we could probably easily have a patch that would scrunch the major minor device numbers down to the 32 bit format but I think it would be better to fix it properly with a protocol change as long as something's being changed. I don't think it's worth a configure warning, just fix it. This will take a protocol change to fix. I think probably rsync should split out the major and minor numbers as two separate 4 byte quantities. I wonder if there are other 64 bit stat values that are being misinterpreted. I agree, and added it to TODO. We will need this on Linux as well, though it's anybody's guess whether devfs and dynamic device numbers will make it mostly irrelevant there. - Dave
Re: Why does one of there work and the other doesn't
On Sun, Dec 02, 2001 at 09:31:25PM -0500, Mark Eichin wrote: | Perhaps a trailing / instead of training /. is supposed to work. I do | not remember why I didn't start using it, but I am sure I would have tried | | Quite possibly because you've been bitten by class cp/rcp; cp is not | idempotent, in that if you cp -r foo bar where foo is a dir and bar | doesn't exist, you end up with a bar that has the contents of foo | (ie. foo/zot - bar/zot) and if you do it twice, cp sees that bar is a | dir and inserts it instead (so foo-bar/foo, foo/zot-bar/foo/zot.) | TO make it worse, on BSD-ish systems, traditionally adding a trailing | slash makes it treat bar as a directory (bar/ == bar/ == bar/.), but | under sysv-ish systems it doesn't change the interpretation (bar/ == | bar, even if bar doesn't exist.) | | Partially *because* of this horror, rsync is (and is documented to be) | consistent, and to have an explicit interpretation of trailing slash | (that is consistent with bar/ == bar/. as far as destinations are | concerned) and is independent of the existence of the destination, so | you can expect it to do the same thing when run twice. This is one | reason i'll often run rsync -a on local files rather than cp -r... I have certainly been bitten by that, and it is not limited to cp and rcp, either. Another example I know that has bitten with disasterous effects is the ln -s command. If the destination does not exist, it puts a symlink there. If the destination exists and is (even if is means a symlink that points to) a directory, it puts the new symlink in the directory named. So doing ln -s twice with a directory target can produce two different symlinks. Even hard links have a problem with target directories, although the twice issue is not relevant since you can't hard link a directory itself (if your system is not broken, unlink pre-ptx Dynix way back in time). On some systems the -n option gets around this on ln -s. I'll do some tests with training / instead of /. to see if that works for me now with 2.5.0. It may have been a bug in an older version. If I get any unexpected results with 2.5.0 I'll report back with those. Consistency is a great value. -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ | -
Re: rsync internationalization?
On Mon, Dec 03, 2001 at 12:16:46AM +1100, Martin Pool wrote: | Does anybody care about supporting non-English message locales in | rsync? (Do all sysadmins speak English? :-) Would anybody contribute | translations if we had the framework? Based on the quality of security and non-open-relay configurations I have seen throughout the internet, I'd say that the vast majority of sysadmins do not read English (or even any language) at all :-) As long as the internationalization does not stuff the executeable with messages of all languages, I'm all for it. For messages that are going to be in the executeable, it might be nice to have a configure time option to specify a language to be integrated if you want something different than the default. I'd contribute Texan but I've only lived in Texas for about 8 years so I really don't know all of the language here, yet :-) -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ | -
Re: rsync internationalization?
- Original Message - From: Phil Howard [EMAIL PROTECTED] I'd contribute Texan but I've only lived in Texas for about 8 years so I really don't know all of the language here, yet :-) -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ | - This may help... http://www.dot-biz.com/IPv4/Tutorial/ The Netfilter Project: Packet Mangling for Linux 2.4 http://netfilter.samba.org Jim Fleming http://www.IPv8.info IPv16One Better !!
Re: Bug in rsyncd 2.5.0 while handling config file string values
Well, that's a bug, I'd reckon, but i want to point out that a config file
with only one line is invalid. you need to have at least a module and its
path defined. I wouldn't expect daemon mode to gracefully handle an
invalid config, though simply declaring that the file is invalid and
exiting would be nice.
Tim Conway
[EMAIL PROTECTED]
303.682.4917
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, n9hmg on AIM
perl -e 'print pack(,
19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970),
.\n '
There are some who call me Tim?
Heikki Vatiainen [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
12/02/2001 06:14 AM
To: [EMAIL PROTECTED]
cc: (bcc: Tim Conway/LMT/SC/PHILIPS)
Subject:Bug in rsyncd 2.5.0 while handling config file string values
Classification:
I compiled and tried rsync 2.5.0 but could not get the server
running. loadparm.c:string_set() now calls free() which it did not do
in 2.4.6 and this free() tries to free memory that was not allocated
with malloc.
Here is a gdb run (done after adding return before fork() in
become_daemon) which shows where it crashes and what my minimal config
file for demonstrating the bug was. The config file only had one line
which was: uid = foobar
/usr/local/src/rsync/rsync-2.5.0:gdb ./rsync
GNU gdb 5.0.90-cvs (MI_OUT)
(gdb) r --daemon --config=../rsyncd.conf
Starting program: /usr/local/src/rsync/rsync-2.5.0/./rsync --daemon
--config=../rsyncd.conf
Program received signal SIGSEGV, Segmentation fault.
0x4009cb2d in free () from /lib/libc.so.6
(gdb) bt
#0 0x4009cb2d in free () from /lib/libc.so.6
#1 0x08061286 in string_set (s=0x807ace4, v=0x808b374 foobar) at
loadparm.c:400
#2 0x08061a20 in lp_do_parameter (snum=-2, parmname=0x808b370 uid,
parmvalue=0x808b374 foobar)
at loadparm.c:647
#3 0x08061b8b in do_parameter (parmname=0x808b370 uid,
parmvalue=0x808b374 foobar) at loadparm.c:678
#4 0x0806057b in Parameter (InFile=0x808b200, pfunc=0x8061b58
do_parameter, c=0) at params.c:405
#5 0x080606a4 in Parse (InFile=0x808b200, sfunc=0, pfunc=0x8061b58
do_parameter) at params.c:461
#6 0x08060848 in pm_process (FileName=0xb80c ../rsyncd.conf,
sfunc=0,
pfunc=0x8061b58 do_parameter) at params.c:540
#7 0x08061cc7 in lp_load (pszFname=0x808b1c0 ../rsyncd.conf,
globals_only=1) at loadparm.c:747
#8 0x08063095 in daemon_main () at clientserver.c:506
#9 0x0805225a in main (argc=0, argv=0x0) at main.c:817
#10 0x400476ef in __libc_start_main () from /lib/libc.so.6
(gdb) select 1
(gdb) p s
$1 = (char **) 0x807ace4
(gdb) p *s
$2 = 0x807680c nobody
(gdb) p sDefault
$3 = {name = 0x0, path = 0x0, comment = 0x0, lock_file = 0x8076813
/var/run/rsyncd.lock,
read_only = 1, list = 1, use_chroot = 1, transfer_logging = 0,
ignore_errors = 0,
uid = 0x807680c nobody, gid = 0x807680c nobody, hosts_allow = 0x0,
hosts_deny = 0x0,
auth_users = 0x0, secrets_file = 0x0, strict_modes = 1, exclude = 0x0,
exclude_from = 0x0,
include = 0x0, include_from = 0x0, log_format = 0x80767f3 %o %h [%a] %m
(%u) %f %l,
refuse_options = 0x0, dont_compress = 0x80767c0 *.gz *.tgz *.zip *.z
*.rpm *.deb *.iso *.bz2 *.tbz,
timeout = 0, max_connections = 0, ignore_nonreadable = 0}
(gdb) shell cat ../rsyncd.conf
uid = foobar
(gdb)
--
Heikki Vatiainen * [EMAIL PROTECTED]
Tampere University of Technology * Tampere, Finland
Re: rsync-2.5.1pre1 with -F option
I always get that too. I just figured i'd screwed something up.
solaris 7
Tim Conway
[EMAIL PROTECTED]
303.682.4917
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, n9hmg on AIM
perl -e 'print pack(,
19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970),
.\n '
There are some who call me Tim?
Ayamura KIKUCHI [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
12/02/2001 11:09 AM
To: [EMAIL PROTECTED]
cc: (bcc: Tim Conway/LMT/SC/PHILIPS)
Subject:rsync-2.5.1pre1 with -F option
Classification:
I compiled and tried rsync 2.5.1pre1.
RSYNC with -F option dumps a core.
% gdb ./rsync
GNU gdb 5.1
(gdb) r -F
Starting program: /work/rsync-2.5.1pre1/./rsync -F
Program received signal SIGSEGV, Segmentation fault.
write_batch_argvs_file (orig_argc=-2, argc=0, argv=0x0) at batch.c:153
153if ( !strcmp(argv[i],-F) ){ /* safer to change it here
than script*/
...
-- ayamura
Re: bug in permissions on symlinks
On Sun, Dec 02, 2001 at 11:52:08PM +1100, Martin Pool wrote: I see rsync has this in rsync.h #ifndef HAVE_LCHOWN #define lchown chown #endif So on Linux lchown changes the ownership on a symlink, whereas chown on a symlink will change the ownership of its target. man lchown says In versions of Linux prior to 2.1.81 (and distinct from 2.1.46), chown did not follow symbolic links. Since Linux 2.1.81, chown does follow symbolic links, and there is a new system call lchown that does not follow symbolic links. Since Linux 2.1.86, this new call (that has the same semantics as the old chown) has got the same syscall number, and chown got the newly introduced number. I'm not at all sure the way we're calling it is correct. There could be systems where there is no lchown, but chown on a symlink still follows the link. I seem to remember Solaris behaving this way, but I'm not sure if that is the system call or just the chown command. In this case we might be accidentally setting the ownership of the destination. On such a machine we should just not set the ownership of the symlink at all. (To be really tricky I guess we could seteuid() before creating the link.) David, do you have a machine that behaves like this? No, I don't. Even my oldest systems have symbolic links and also have lchown. I think any system that has symbolic links would have to implement the lchown/chown distinction, so I don't think it's something to worry about. - Dave Dykstra
Re: Why does one of there work and the other doesn't
rsync already has a memory-hogging issue. Imagine having it search your entire directory tree, checksumming all files, storing and sending them all, comparing both lists looking for matching date/time/checksums to guess where you've moved files to. You'd be better off to use a wrapper the tools you move files with, keeping a replayable log, and have your mirrors retrieve and replay that log, before doing the rsync. Tim Conway [EMAIL PROTECTED] 303.682.4917 Philips Semiconductor - Longmont TC 1880 Industrial Circle, Suite D Longmont, CO 80501 Available via SameTime Connect within Philips, n9hmg on AIM perl -e 'print pack(, 19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970), .\n ' There are some who call me Tim? Phil Howard [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 12/03/2001 09:04 AM To: [EMAIL PROTECTED] cc: (bcc: Tim Conway/LMT/SC/PHILIPS) Subject:Re: Why does one of there work and the other doesn't Classification: On Mon, Dec 03, 2001 at 12:09:16AM +1100, Martin Pool wrote: | On 30 Nov 2001, Randy Kramer [EMAIL PROTECTED] wrote: | | I am not sure which end the 100 bytes per file applies to, and I guess | that is the RAM memory footprint?. Does rsync need 100 bytes for each | file that might be transferred during a session (all files in the | specified directory(ies)), or does it need only 100 bytes as it does one | file at a time? | | At the moment that is 100B for all files to be transferred in the | whole session. This is a big limit to scalability at the moment, and | a goal of mine is to reduce it to at most holding file information | from a single directory in memory. It would still be nice to have an option to gather all files at once, but this will be of value if it also gathers all the checksums and syncronizes files moves that have happened on the source end by doing the syncronization of the moved file to the new location using the old (checksum matched) file on the destination end. Right now if a file gets moved from one location to another (especially in a different directory, which is often the case with a re-organization) things get retransferred even though most every file already exists somewhere on the destination. -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ | -
-v prints directories twice
Does it bother anybody else that -v prints directories twice? It first prints all affected directories and files in recursive order and then prints new directories again. I can't recall noticing that rsync always did that, but I don't think it's a very recent change. The directory is being printed both times by recv_generator(), and I checked CVS and it's been there since the beginning of generator.c. Investigation told me that the second time around it is fixing up the modification time directories that had some file in them change during the run, done by a special call from recv_files() in receiver.c. I note that on that special call, the f_out parameter is set to -1 so the following little patch fixes it. I think this is simple enough that I'll just submit it to the rsync CVS as one of the small changes I put in. - Dave Dykstra --- generator.c.O Mon Dec 3 12:29:31 2001 +++ generator.c Mon Dec 3 12:27:04 2001 @@ -247,7 +247,9 @@ fname,strerror(errno)); } } - if (set_perms(fname,file,NULL,0) verbose) + /* f_out is set to -1 when doing final directory + permission and modification time repair */ + if (set_perms(fname,file,NULL,0) verbose (f_out != -1)) rprintf(FINFO,%s/\n,fname); return; }
--help output too long?
On Mon, Dec 03, 2001 at 12:15:41AM +1100, Martin Pool wrote: Subject: Re: --no-detach option? I'm starting to think we need to not show all the options in the default --help output. I think perhaps the default should be to show the commonly-used options (-avz, --include, : vs ::) and then have --help-options and so on for more details. It is getting quite ridiculous. There's one or two packages that do this, but I can't remember which ones right at the moment. I think the current way is OK. Other commands have long lists too, for example gpg and wget. They do both put them in labeled groups, however. That's a possibility, although I can't think of any nice logical grouping off the top of my head. - Dave Dykstra
question on permissions
I have a question regarding how rsync changes ownership when syncing two areas. Currently, I have this situation: I have two areas over a WAN, we are trying to mirror from one site to another. One site is not controlled by us and has different unix groups. When we copy one to the other, we are running rsync on an account that exists at both places (different UIDs though) In one area we have no problems the groups/owners exist at both places. However in another area, the owner exists but the group name does not. When we run rsync between the two we get a lot of chown errors. Now this makes sense as some OSs (we are using HPUX 11) do not allow a person to change the ownership of a file. However, we have another area where both the group and the ownership exist on both ends but we have no chown errors. Can anybody explain this behavior? In the end, the area still gets owned by the uid and gid of the rsync running on our end. Thanks, sri
Re: question on permissions
On Mon, Dec 03, 2001 at 01:21:29PM -0800, Sri Ramkrishna wrote: I have a question regarding how rsync changes ownership when syncing two areas. Currently, I have this situation: I have two areas over a WAN, we are trying to mirror from one site to another. One site is not controlled by us and has different unix groups. When we copy one to the other, we are running rsync on an account that exists at both places (different UIDs though) In one area we have no problems the groups/owners exist at both places. However in another area, the owner exists but the group name does not. When we run rsync between the two we get a lot of chown errors. Now this makes sense as some OSs (we are using HPUX 11) do not allow a person to change the ownership of a file. However, we have another area where both the group and the ownership exist on both ends but we have no chown errors. Can anybody explain this behavior? In the end, the area still gets owned by the uid and gid of the rsync running on our end. Thanks, sri Are you using rsync --daemon mode on one side? There are several tricky issues related to that, alluded to under the --owner option in the rsync man page. What user id are you doing the transfers under? Also, rsync enforces bsd-style ownership and group semantics, regardless of whether or not the underlying operating system permits more freedom with chown and chgrp. That means it won't allow doing a chown to another user if you're not root, and the only groups it will allow a non-privileged user to chgrp to are those which groups which the user belongs to. - Dave Dykstra
Re: question on permissions
On Mon, Dec 03, 2001 at 04:05:12PM -0600, Dave Dykstra wrote: On Mon, Dec 03, 2001 at 01:21:29PM -0800, Sri Ramkrishna wrote: I have a question regarding how rsync changes ownership when syncing two areas. Currently, I have this situation: I have two areas over a WAN, we are trying to mirror from one site to another. One site is not controlled by us and has different unix groups. When we copy one to the other, we are running rsync on an account that exists at both places (different UIDs though) In one area we have no problems the groups/owners exist at both places. However in another area, the owner exists but the group name does not. When we run rsync between the two we get a lot of chown errors. Now this makes sense as some OSs (we are using HPUX 11) do not allow a person to change the ownership of a file. However, we have another area where both the group and the ownership exist on both ends but we have no chown errors. Can anybody explain this behavior? In the end, the area still gets owned by the uid and gid of the rsync running on our end. Thanks, sri Are you using rsync --daemon mode on one side? There are several tricky issues related to that, alluded to under the --owner option in the rsync man page. Well, no, I'm not using --daemon mode at all. I'm just rsh and forking a rsync process on the other side. What user id are you doing the transfers under? Well the login id is the same between the sites. But the uid of the user id is different. (shouldn't matter) We have some wierd permission problems so when I run the rsync on our end I'm running it this way: su - ptmda some_rsync_script I had to do this because we use something called Powerbroker to share accounts and somehow there is some confusion with how it gets executed under what ID. We just added the group that we didn't have that the other site did and that solved our problem with chown errors. Very weird. So it looks like both the group and the owner must exist at both sites in order to avoid errors? Also, rsync enforces bsd-style ownership and group semantics, regardless of whether or not the underlying operating system permits more freedom with chown and chgrp. That means it won't allow doing a chown to another user if you're not root, and the only groups it will allow a non-privileged user to chgrp to are those which groups which the user belongs to. I think thats it right there. The owner did not belong to the group. We changed it so that the owner had the missing group in there and that fixed it. Thanks!! Much appreciated! sri
Re: Why does one of there work and the other doesn't
On Mon, Dec 03, 2001 at 09:55:53AM -0700, [EMAIL PROTECTED] wrote: | rsync already has a memory-hogging issue. Imagine having it search your | entire directory tree, checksumming all files, storing and sending them | all, comparing both lists looking for matching date/time/checksums to | guess where you've moved files to. You'd be better off to use a wrapper | the tools you move files with, keeping a replayable log, and have your | mirrors retrieve and replay that log, before doing the rsync. I don't think so. I would like to have that kind of smart capability be fully integrated into a useful tool. And rsync already has most of the pieces such a thing would need in place. I am NOT suggesting that it be the default. As you say, it would be memory hogging. But it is already memory hogging now, and adding a checksum for every file in the tree would be 32 bytes more per file. In some cases I definitely want LESS memory hogging, such as replicating trees of millions of files. In other cases I do want the checksumming to get LESS files redundantly transferred. What I have done in the past to accomplish it is to build a tar file of the entire tree on both sides, then sync the tar files making sure the rsync blocksize matches correctly. That still takes a lot of time because rsync is sending a LOT of checksum for small blocks. If I could get tar to build the tar file with the files on very large block boundaries, then I could specify a larger blocksize to rsync and do the transfer much faster. But it would make just as much sense to just send a checksum per file, and, in cases where a whole file checksum matches (though at a different name on the destination) to copy, hardlink, or move (as appropriate) the file to the new location. Inventing a whole new tool to do this when rsync has most of the logic of it in place is absurd. I just don't understand the actual rsync internals or protocol enough to accomplish such a patch myself, so my only option is to offer the suggestion and hope someone likes it. Again, I am not suggesting that it be the default option, so it would nt impact anyone unless they wanted it to. -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ | -
Netware modify bit changed
Hi, I run rsync, with a Netware-directory mounted on a linux system (using ncpfs) as DESTINATION of the copy. This configuration works fine, but rsync incorrectly sets the archive bit (modify) for ALL the files included in the transfered directory (both modified and not modified). In consecuence, the incremental backups on my netware server don't work. Any help will be apreciated. Regards, Juan J. Lopez
Re: rsync ipv6 patch merge?
In article [EMAIL PROTECTED] (at Tue, 4 Dec 2001 16:45:43 +1100),
Martin Pool [EMAIL PROTECTED] says:
Would it be sufficient for us to just read into a byte array large
enough to hold all reasonable IPv6 encodings, and then cast it as
appropriate? I have not had a chance to follow this idea through yet.
Put sockaddr_storage{} delaration in appropriate header
in rsync distribution and enclose it with #ifdef ... #endif.
Then use it on sockaddr_storage{}-missed platforms.
Or, if we can give up ipv6 support on a such platform, just do
#define sockaddr_storage sockaddr
#define ss_family sa_family /* if needed */
or so if it has no sockaddr_storage{}.
--yoshfuji
Re: rsync ipv6 patch merge?
Would it be sufficient for us to just read into a byte array large
enough to hold all reasonable IPv6 encodings, and then cast it as
appropriate? I have not had a chance to follow this idea through yet.
I don't think at most 240 byte larger array has bad influence to
system. Moreover all of sokcaddr_storage in rsync are auto-variable.
Here is new patch for rsync-current which including compatible
checking. Please try it in missing sockaddr_storage system.
Some systems may not have typedef u_int{8,32}_t.
I'm not sure whether we should use u_short/u_long instead of them.
Regards,
---
Munechika SUMIKAWA @ KAME Project
Index: config.h.in
===
RCS file: /cvsroot/rsync/config.h.in,v
retrieving revision 1.64
diff -u -r1.64 config.h.in
--- config.h.in 28 Nov 2001 03:12:20 - 1.64
+++ config.h.in 4 Dec 2001 06:56:15 -
@@ -8,6 +8,7 @@
#undef HAVE_GETTIMEOFDAY_TZ
#undef ENABLE_IPV6
#undef HAVE_SOCKADDR_LEN
+#undef HAVE_SOCKADDR_STORAGE
#undef HAVE_SOCKETPAIR
/* Define to turn on debugging code that may slow normal operation */
Index: configure.in
===
RCS file: /cvsroot/rsync/configure.in,v
retrieving revision 1.112
diff -u -r1.112 configure.in
--- configure.in2 Dec 2001 22:26:09 - 1.112
+++ configure.in4 Dec 2001 06:56:21 -
@@ -284,6 +284,14 @@
#include sys/socket.h
])
+AC_MSG_CHECKING(struct sockaddr_storage)
+AC_TRY_COMPILE([#include sys/types.h
+#include sys/socket.h],
+[struct sockaddr_storage x;],
+ AC_MSG_RESULT(yes)
+ AC_DEFINE(HAVE_SOCKADDR_STORAGE),
+ AC_MSG_RESULT(no))
+
# if we can't find strcasecmp, look in -lresolv (for Unixware at least)
#
AC_CHECK_FUNCS(strcasecmp)
Index: socket.c
===
RCS file: /cvsroot/rsync/socket.c,v
retrieving revision 1.45
diff -u -r1.45 socket.c
--- socket.c27 Nov 2001 06:01:05 - 1.45
+++ socket.c4 Dec 2001 06:56:21 -
@@ -372,8 +372,8 @@
while (1) {
fd_set fds;
int fd;
- struct sockaddr addr;
- int in_addrlen = sizeof(addr);
+ struct sockaddr_storage addr;
+ int addrlen = sizeof(addr);
/* close log file before the potentially very long select so
file can be trimmed by another process instead of growing
@@ -389,7 +389,7 @@
if(!FD_ISSET(s, fds)) continue;
- fd = accept(s,(struct sockaddr *)addr,in_addrlen);
+ fd = accept(s,(struct sockaddr *)addr,addrlen);
if (fd == -1) continue;
@@ -555,7 +555,7 @@
**/
char *client_addr(int fd)
{
- struct sockaddr ss;
+ struct sockaddr_storage ss;
int length = sizeof(ss);
static char addr_buf[100];
static int initialised;
@@ -564,11 +564,11 @@
initialised = 1;
- if (getpeername(fd, ss, length)) {
+ if (getpeername(fd, (struct sockaddr *)ss, length)) {
exit_cleanup(RERR_SOCKETIO);
}
- getnameinfo(ss, length,
+ getnameinfo((struct sockaddr *)ss, length,
addr_buf, sizeof(addr_buf), NULL, 0, NI_NUMERICHOST);
return addr_buf;
}
@@ -579,7 +579,7 @@
**/
char *client_name(int fd)
{
- struct sockaddr ss;
+ struct sockaddr_storage ss;
int length = sizeof(ss);
static char name_buf[100];
static char port_buf[100];
@@ -602,7 +602,7 @@
}
#ifdef INET6
-if (ss.sa_family == AF_INET6
+if (ss.ss_family == AF_INET6
IN6_IS_ADDR_V4MAPPED(((struct sockaddr_in6 *)ss)-sin6_addr)) {
struct sockaddr_in6 sin6;
struct sockaddr_in *sin;
@@ -646,7 +646,7 @@
/* XXX sin6_flowinfo and other fields */
for (res = res0; res; res = res-ai_next) {
- if (res-ai_family != ss.sa_family)
+ if (res-ai_family != ss.ss_family)
continue;
if (res-ai_addrlen != length)
continue;
Index: lib/addrinfo.h
===
RCS file: /cvsroot/rsync/lib/addrinfo.h,v
retrieving revision 1.6
diff -u -r1.6 addrinfo.h
--- lib/addrinfo.h 27 Nov 2001 03:46:03 - 1.6
+++ lib/addrinfo.h 4 Dec 2001 06:56:21 -
@@ -102,6 +102,18 @@
struct addrinfo *ai_next; /* next structure in linked list */
};
+#ifndef HAVE_SOCKADDR_STORAGE
+struct sockaddr_storage {
+#ifdef HAVE_SOCKADDR_LEN
+ u_int8_tss_len; /* address length */
+ u_int8_tss_family; /* address family */
+#else
+ u_int16_t ss_family;
+#endif
+ u_int8_t fill[126];
+};
+#endif
+
extern void freehostent(struct hostent *);
extern char *gai_strerror(int);
#endif /*
Re: rsync ipv6 patch merge?
On 4 Dec 2001, SUMIKAWA Munechika [EMAIL PROTECTED] wrote:
Would it be sufficient for us to just read into a byte array large
enough to hold all reasonable IPv6 encodings, and then cast it as
appropriate? I have not had a chance to follow this idea through yet.
I don't think at most 240 byte larger array has bad influence to
system. Moreover all of sokcaddr_storage in rsync are auto-variable.
Here is new patch for rsync-current which including compatible
checking. Please try it in missing sockaddr_storage system.
Some systems may not have typedef u_int{8,32}_t.
I'm not sure whether we should use u_short/u_long instead of them.
Yes, we do build on systems which do not have them built in. We
normally use uchar and uint32, though note that on systems such as
CRAY they may actually be larger.
Thankyou,
--
Martin
Re: rsync ipv6 patch merge?
On 4 Dec 2001, SUMIKAWA Munechika [EMAIL PROTECTED] wrote: client_addr(), client_name() always fails for IPv6 connection sice in most of system, sizeof(struct sockaddr_in) sizeof(struct sockaddr) sizeof(struct sockaddr_in6) you should use sockaddr_storage for getpeername(). here is the patch. Yes, I'm aware of that. The problem is that the patch originally used would not compile on a significant number of platforms which are missing sockaddr_storage. Would it be sufficient for us to just read into a byte array large enough to hold all reasonable IPv6 encodings, and then cast it as appropriate? I have not had a chance to follow this idea through yet. Thankyou, -- Martin
