Please test rsync-2.5.6pre2
The second rsync-2.5.6 pre-release version is now available at: http://rsync.samba.org/ftp/rsync/preview/rsync-2.5.6pre2.tar.gz ftp://rsync.samba.org/pub/rsync/preview/rsync-2.5.6pre2.tar.gz rsync://rsync.samba.org/ftp/rsync/preview/rsync-2.5.6pre2.tar.gz There's also a corresponding '.sig' file that contains a gpg signature of the file; the public key is available on the pgp keyservers. This is a release candidate. If no-one reports an urgent fixes within the next few days, it will probably become version 2.5.6. Known issues that will probably not get resolved before the release unless a volunteer provides a solution: 1. The NetBSD i386 port is failing the chgrp test. See build output on build.samba.org. 2. I just noticed that the cygwin chgrp test has timestamps off by two seconds. Maybe --modify-window is supposed to be 1? Changes since 2.5.5pre1: ENHANCEMENTS: * Set the default value of --modify-window to 2 on Cygwin. (Max Bowsher) * Ignore errors from chmod when -p/-a/--preserve-perms is not set. (Dave Dykstra) BUG FIXES: * Fixed the file-name duplicate-removal code when dealing with multiple dups in a row. (Wayne Davison) * Fixed bug in --copy-unsafe-links that caused it to be completely broken. (Dave Dykstra) * Prevent infinite recursion in cleanup code under certain circumstances. (Sviatoslav Sviridov) * Fixed a bug that prevented rsync from creating intervening directories when --relative-paths/-R is set. (Craig Barratt) INTERNAL: * Portability fixes. (Dave Dykstra and Wayne Davison) - Dave Dykstra msg06197/pgp0.pgp Description: PGP signature
Re: Q : Rsync verbose message
On Tue, Jan 21, 2003 at 10:46:56AM +0900, Yuji Sato wrote: > wrote 30 bytes read 200 bytes 60.00 bytes/sec > total size is 4000 speedup is 125.30 > > "bytes/sec" > Is this figure only as a result of a file transfer? > Or is it the total result of since the rsync command is performed? That figure is the total bytes transferred divided by the total time that rsync was running. > I had connected by gigabit(1000Base-T & 1000Base-SX), I hope more better > results. Rsync's main purpose is to work over slow networks, so it uses CPU to avoid network transfer. On a gigabit network, you're probably CPU bound, and thus not able to use all the network bandwidth. Try using the -W (--whole-file) option. > "speedup is" > Is this that processing of only a file transfer took 125.30 seconds? No, this is the multiplier of the bytes transferred compared to the total size of all the files that either were or could have been transferred. In other words, if you divide the total size (which includes all files that it scanned) by 125.30, that should equal the bytes actually sent over the wire. When the network is the limiting factor in a transfer, this tells you how much faster the transfer actually went. When the network is not the limiting factor, it's really just a compression factor. ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Q : Rsync verbose message
Hi, I am using rsync for file server mirroring by Linux(Redhat7.2). Please tell me, How to read about rsync last verbose message. wrote 30 bytes read 200 bytes 60.00 bytes/sec total size is 4000 speedup is 125.30 "bytes/sec" Is this figure only as a result of a file transfer? Or is it the total result of since the rsync command is performed? I had connected by gigabit(1000Base-T & 1000Base-SX), I hope more better results. "speedup is" Is this that processing of only a file transfer took 125.30 seconds? I'd like to find to bottle neck. regards Yujis -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: am I missing something, or are permissions always preserved?
On Mon, Jan 20, 2003 at 07:00:55PM -0600, Dave Dykstra wrote: > I submitted a change to ignore errors from chmod when -p is not set. > GNU cp does the same thing. > > - Dave Dykstra Fair enough. It is an isane condition except for filesystem semantics mismatch. > On Mon, Jan 13, 2003 at 01:13:48PM -0800, jw schultz wrote: > > On Mon, Jan 13, 2003 at 02:38:29PM -0600, Dave Dykstra wrote: > > > On Mon, Jan 13, 2003 at 11:00:58AM -0800, Ben wrote: > > > > As a rule of thumb, I think silent errors a very bad idea. It means > > > > things might not be behaving like you expect, but you have no idea. In > > > > general, rsync's current behavior is correct. In my case niche case, it > > > > doesn't work. I think the proper solution is to change rsync's behavior, > > > > not reduce the errors it produces. > > > > > > Maybe it wouldn't be so bad if it only looked for certain error codes from > > > the failed chmod. The nice thing about ignoring errors is that it's one > > > less thing for users to have to learn and understand. > > > > > > Any other opinions? > > > > First, identify the errno. Is it the same for cygwin and > > samba mounts? Then do the treatment for that errno(s) only. > > > > As far as i can tell except where the filesystem doesn't > > support chmod an error chmoding here is insane. We just > > created the file. > > > > I'd rather kick out a warning on the first one and then > > ignore. That warns the user that something isn't quite > > right without flooding the log. > > > > Dave, see my post a litter earlier in the thread for a > > possible code change. -- J.W. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: am I missing something, or are permissions always preserved?
I submitted a change to ignore errors from chmod when -p is not set. GNU cp does the same thing. - Dave Dykstra On Mon, Jan 13, 2003 at 01:13:48PM -0800, jw schultz wrote: > On Mon, Jan 13, 2003 at 02:38:29PM -0600, Dave Dykstra wrote: > > On Mon, Jan 13, 2003 at 11:00:58AM -0800, Ben wrote: > > > Well that's annoying. I've tried changing the encoding of this > > > attempt... maybe it'll get through this time. > > > > Yes, it came through better this time. > > > > > As a rule of thumb, I think silent errors a very bad idea. It means > > > things might not be behaving like you expect, but you have no idea. In > > > general, rsync's current behavior is correct. In my case niche case, it > > > doesn't work. I think the proper solution is to change rsync's behavior, > > > not reduce the errors it produces. > > > > Maybe it wouldn't be so bad if it only looked for certain error codes from > > the failed chmod. The nice thing about ignoring errors is that it's one > > less thing for users to have to learn and understand. > > > > Any other opinions? > > First, identify the errno. Is it the same for cygwin and > samba mounts? Then do the treatment for that errno(s) only. > > As far as i can tell except where the filesystem doesn't > support chmod an error chmoding here is insane. We just > created the file. > > I'd rather kick out a warning on the first one and then > ignore. That warns the user that something isn't quite > right without flooding the log. > > Dave, see my post a litter earlier in the thread for a > possible code change. > > > > > > If it comes through, take a look at the patch. I think I did a decent > > > job of updating the docs so that purpose of the new flag is clear. > > > > At a minimum I think the option is too limited. I'd want a solution > > that would work for both the fixed permission samba case and the vfat > > filesystem under Linux case. In particular, I don't see it skipping > > the fchmod in do_mkstemp. I don't know, maybe that's the only addition > > that would be needed. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: possible typo/bug in receiver.c
On Sat, Jan 18, 2003 at 12:25:05AM -0800, Wayne Davison wrote: > On Fri, Jan 17, 2003 at 11:39:31PM -0800, Craig Barratt wrote: > > If mkstemp() fails (for various reasons, including the directory not > > existing) then fd == -1. So the first if () executes, which flushes > > the data and does a continue. So the next two if () statements will > > never execute. > > Good catch. The code got tweaked into this form in version 1.32 when it > was changed from a set of calls (using do_mktemp() and do_open()) into a > single call (using just do_mkstemp()). At that point the new (simpler) > error-check section got added, and it made it impossible to get down to > the older section. > > > Is rsync meant to create deep directories that don't exist? > > Not usually. In -R mode, it sends implied directories for the files, so > it should be the case that the directories are normally created already. > I find it interesting that this old code exists because there has been a > lot of talk about the sending of implied directories (and an option to > turn this off). If we put this code back the way it was back in 2001, > then the newly suggested --no-implied-dirs option would not cause rsync > to fail if a deep file didn't have a directory yet -- rsync would just > create the intervening directories. I'm not sure if I want it to do > that or not at the moment. > > ...wayne.. I removed the error check that skipped the creation of the directory, just a piece of the code that was added in version 1.32. It's pretty clear to me that it was just an oversight, because Tridge also modified the dead code leg. - Dave -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: IPv6 hosts allow|deny
Thanks for the quick tutorial. I submitted your patch, changing eth0 to link1 as Hideaki suggested. - Dave On Mon, Jan 20, 2003 at 06:35:09PM +0100, Bert Vermeulen wrote: > On Mon, 20 Jan 2003, Dave Dykstra wrote: > > > On Fri, Jan 17, 2003 at 12:31:26AM +0100, Bert Vermeulen wrote: > > > On Mon, 13 Jan 2003, Dave Dykstra wrote: > > > > > > > I don't understand enough how that syntax works in order to be able > > > > to write an explanation for people. Could you please try to write > > > > something up based on the current version checked in to CVS? > > > > > > Here's a patch for the manpage: > > > > > > http://biot.com/patches/rsync-ipv6-acl-doc.patch > > > > I have never been introduced to IPv6 addresses before and there are some > > things about your documentation that baffle me. Perhaps I just need to > > be educated a little, or perhaps it would be useful to include a little > > more explnation in the documentation. > > > > Your patch includes this: > > > - it() a dotted decimal IP address of the form a.b.c.d for IPv4 and > > > - a.b.c.d.e.f for IPv6. In this case the incoming machine's IP address > > > + it() a dotted decimal IPv4 address of the form a.b.c.d, or an IPv6 address > > > + of the form a:b:c::d:e:f. In this case the incoming machine's IP address > > >must match exactly. > > > > Why is there a blank field between "c" and "d"?Do you think you > > should you say something about the fields being hexadecimal for IPv6, > > or is that obvious to anyone who has seen IPv6 addresses before? > > What Hideaki said, RFC 2373 describes the address format for IPv6. > > But yes, if you've ever dealt with IPv6, certainly this is obvious. I don't > think it really needs explaining in the rsync docs as such... If you have > IPv6 working on the machine, you pretty much already know the address > format. > > Anyway, briefly... :: denotes a number of 0 values, it's an abbreviation. > You can only do this once per IPv6 address. It's exactle the same as writing > this: > > 000a:000b:000c:::000d:000e:000f > > So you can see how a:b:c::d:e:f is easier to type. This is standardized > stuff, so you're guaranteed to be able to type that into anything that > parses IPv6 addresses. > > > Your patch also includes this: > > > + it() an address/mask in the form ipaddr/n where ipaddr is the IP address > > > + and n is the number of one bits in the netmask. All IP addresses which > > > + match the masked IP address will be allowed in. > > > + > > > + it() an address/mask in the form ipaddr/maskaddr where ipaddr is the > > > + IP address and maskaddr is the netmask in dotted decimal notation for IPv4, > > > + or similar for IPv6, e.g. ::::: instead of /64. All IP > > > + addresses which match the masked IP address will be allowed in. > > > > > > How come a mask includes 4 fields followed by 2 blanks? What do you > > mean by "/64"? > > The /64 is just CIDR notation as used in IPv4 as well, i.e. the number of 1 > bits in the network mask. In IPv4, they go up to 32, where a /32 means a > host. With IPv6, they go up to /128 for a host, however /64 is the > "standard" netmask for a subnet. > > > Your patch also has this addition: > > > +Note IPv6 link-local addresses can have a scope in the address specification: > > > + > > > +quote(fe80::1%eth0) > > > +quote(fe80::%eth0/64) > > > +quote(fe80::%eth0/:::::) > > > > What's a link-local address? > > An address that is only valid for a certain link, i.e. only reachable > through that interface. Thus the special prefix (fe80) -- and naturally, > those are only useful if you specify the interface as well, as you might > have the same link-local address on two different interfaces. > > > What's a scope? > > In the case of a link-local address, the scope of an interface would be the > subnet behind it. > > > I think I get that the parts after the '/' are masks, but what does it > > mean to have just two colons in the address, with one field blank and the > > third one either 1%eth0 or %eth0? > > The 1 is the last part of the address. It goes on until the "%", which > denotes the start of the interface specification. The "/64" after the > interface is indeed the netmask. > > > Bert Vermeulen > [EMAIL PROTECTED] -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Windows and default --modify-window=0
I submitted a patch similar to what Max suggested. Nobody came up with a definitive answer on whether the modify-window default should be 1 or 2 so I left it at 2. - Dave On Fri, Jan 10, 2003 at 06:27:31PM -, Max Bowsher wrote: > Dave Dykstra wrote: > > Ok, I agree --modify-window should default to 2 (or 1 if that's all > > that's really needed) on cygwin. However, I don't like os-specific > > defines. > > They have the advantage that the entire logic is visible in the .c file, > rather than split between the .c and configure.in. > > > That _WIN32 we've got there is the only one currently in the code, and > > there's no occurrances of __CYGWIN__. I'd rather have a configure.in > > rule for it. Any suggestions on a good one? At a minimum there's an > > AC_CYGWIN macro but that's not much different than just checking for > > __CYGWIN__. Probably it would be worth calling AC_CYGWIN and then > > setting > > a DEFAULT_MODIFY_WINDOW to 2 in configure if $CYGWIN=yes. > > AC_CYGWIN is obsolete - the autoconf manual recommends something like this: > AC_CANONICAL_HOST # at some point above > case $host_os in > *cygwin* ) DEFAULT_MODIFY_WINDOW=2;; > * ) DEFAULT_MODIFY_WINDOW=0;; > esac > AC_SUBST(DEFAULT_MODIFY_WINDOW) > > As far as I > > know there is no other port of rsync to Windows yet except under > > Cygwin > > so I don't think it is worth putting in extra code to support > > something > > that may never be used. Or, perhaps we should key off of the $EXEEXT > > variable which gets set to '.exe' on Windows; anybody have an opinion > > on > > that? > > Yuk! :-) > > > > Max. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
once again: strange characters
Hi all, I'm currently testing the Novell Netware version of Rsync 2.5.5. I use a RH 80 linux client, the Novell server runs the daemon. The Novell server has 850 (=latin1 ?) as codepage and users sometimes create filenames with "odd" (international) characters in them. These appear to be converted into other characters or question marks by rsync, or are simply left out. I've had the same thing while ll doing rsyncs on NT with Cygwin. I've solved it back then by changing codepages and one registry entry. Anyone any idea what to do to get this fixed? Just change the codepage on the linuxbox? Or something additional? Thx already! Bart Coninckx Network Administrator CNE, ASE * Sita ICT Services Lilsedijk 19 B-2340 Beerse Belgium e-mail: [EMAIL PROTECTED] Tel: + 32 (0) 14 62 28 22 Fax: + 32 (0) 14 62 41 47 * -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: IPv6 hosts allow|deny
On Mon, 20 Jan 2003, Dave Dykstra wrote: > On Fri, Jan 17, 2003 at 12:31:26AM +0100, Bert Vermeulen wrote: > > On Mon, 13 Jan 2003, Dave Dykstra wrote: > > > > > I don't understand enough how that syntax works in order to be able > > > to write an explanation for people. Could you please try to write > > > something up based on the current version checked in to CVS? > > > > Here's a patch for the manpage: > > > > http://biot.com/patches/rsync-ipv6-acl-doc.patch > > I have never been introduced to IPv6 addresses before and there are some > things about your documentation that baffle me. Perhaps I just need to > be educated a little, or perhaps it would be useful to include a little > more explnation in the documentation. > > Your patch includes this: > > - it() a dotted decimal IP address of the form a.b.c.d for IPv4 and > > - a.b.c.d.e.f for IPv6. In this case the incoming machine's IP address > > + it() a dotted decimal IPv4 address of the form a.b.c.d, or an IPv6 address > > + of the form a:b:c::d:e:f. In this case the incoming machine's IP address > >must match exactly. > > Why is there a blank field between "c" and "d"?Do you think you > should you say something about the fields being hexadecimal for IPv6, > or is that obvious to anyone who has seen IPv6 addresses before? What Hideaki said, RFC 2373 describes the address format for IPv6. But yes, if you've ever dealt with IPv6, certainly this is obvious. I don't think it really needs explaining in the rsync docs as such... If you have IPv6 working on the machine, you pretty much already know the address format. Anyway, briefly... :: denotes a number of 0 values, it's an abbreviation. You can only do this once per IPv6 address. It's exactle the same as writing this: 000a:000b:000c:::000d:000e:000f So you can see how a:b:c::d:e:f is easier to type. This is standardized stuff, so you're guaranteed to be able to type that into anything that parses IPv6 addresses. > Your patch also includes this: > > + it() an address/mask in the form ipaddr/n where ipaddr is the IP address > > + and n is the number of one bits in the netmask. All IP addresses which > > + match the masked IP address will be allowed in. > > + > > + it() an address/mask in the form ipaddr/maskaddr where ipaddr is the > > + IP address and maskaddr is the netmask in dotted decimal notation for IPv4, > > + or similar for IPv6, e.g. ::::: instead of /64. All IP > > + addresses which match the masked IP address will be allowed in. > > > How come a mask includes 4 fields followed by 2 blanks? What do you > mean by "/64"? The /64 is just CIDR notation as used in IPv4 as well, i.e. the number of 1 bits in the network mask. In IPv4, they go up to 32, where a /32 means a host. With IPv6, they go up to /128 for a host, however /64 is the "standard" netmask for a subnet. > Your patch also has this addition: > > +Note IPv6 link-local addresses can have a scope in the address specification: > > + > > +quote(fe80::1%eth0) > > +quote(fe80::%eth0/64) > > +quote(fe80::%eth0/:::::) > > What's a link-local address? An address that is only valid for a certain link, i.e. only reachable through that interface. Thus the special prefix (fe80) -- and naturally, those are only useful if you specify the interface as well, as you might have the same link-local address on two different interfaces. > What's a scope? In the case of a link-local address, the scope of an interface would be the subnet behind it. > I think I get that the parts after the '/' are masks, but what does it > mean to have just two colons in the address, with one field blank and the > third one either 1%eth0 or %eth0? The 1 is the last part of the address. It goes on until the "%", which denotes the start of the interface specification. The "/64" after the interface is indeed the netmask. Bert Vermeulen [EMAIL PROTECTED] -- Profanity is the inevitable linguistic crutch of the inarticulate motherfucker. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: IPv6 hosts allow|deny
In article <[EMAIL PROTECTED]> (at Mon, 20 Jan 2003 10:54:47 -0600), Dave Dykstra <[EMAIL PROTECTED]> says: > I have never been introduced to IPv6 addresses before and there are some > things about your documentation that baffle me. Perhaps I just need to > be educated a little, or perhaps it would be useful to include a little > more explnation in the documentation. RFC2373 Section 2.2 Text Representation of Addresses draft-ietf-ipngwg-scoping-arch-04.txt 12 Textual Representation > > +Note IPv6 link-local addresses can have a scope in the address specification: > > + > > +quote(fe80::1%eth0) > > +quote(fe80::%eth0/64) > > +quote(fe80::%eth0/:::::) > > What's a link-local address? What's a scope? I think I get that the parts > after the '/' are masks, but what does it mean to have just two colons > in the address, with one field blank and the third one either 1%eth0 or > %eth0? BTW, we should use link1 instead of eth0. --yoshfuji -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: IPv6 hosts allow|deny
On Fri, Jan 17, 2003 at 12:31:26AM +0100, Bert Vermeulen wrote: > On Mon, 13 Jan 2003, Dave Dykstra wrote: > > > I don't understand enough how that syntax works in order to be able > > to write an explanation for people. Could you please try to write > > something up based on the current version checked in to CVS? > > Here's a patch for the manpage: > > http://biot.com/patches/rsync-ipv6-acl-doc.patch I have never been introduced to IPv6 addresses before and there are some things about your documentation that baffle me. Perhaps I just need to be educated a little, or perhaps it would be useful to include a little more explnation in the documentation. Your patch includes this: > - it() a dotted decimal IP address of the form a.b.c.d for IPv4 and > - a.b.c.d.e.f for IPv6. In this case the incoming machine's IP address > + it() a dotted decimal IPv4 address of the form a.b.c.d, or an IPv6 address > + of the form a:b:c::d:e:f. In this case the incoming machine's IP address >must match exactly. Why is there a blank field between "c" and "d"?Do you think you should you say something about the fields being hexadecimal for IPv6, or is that obvious to anyone who has seen IPv6 addresses before? Your patch also includes this: > + it() an address/mask in the form ipaddr/n where ipaddr is the IP address > + and n is the number of one bits in the netmask. All IP addresses which > + match the masked IP address will be allowed in. > + > + it() an address/mask in the form ipaddr/maskaddr where ipaddr is the > + IP address and maskaddr is the netmask in dotted decimal notation for IPv4, > + or similar for IPv6, e.g. ::::: instead of /64. All IP > + addresses which match the masked IP address will be allowed in. How come a mask includes 4 fields followed by 2 blanks? What do you mean by "/64"? Your patch also has this addition: > +Note IPv6 link-local addresses can have a scope in the address specification: > + > +quote(fe80::1%eth0) > +quote(fe80::%eth0/64) > +quote(fe80::%eth0/:::::) What's a link-local address? What's a scope? I think I get that the parts after the '/' are masks, but what does it mean to have just two colons in the address, with one field blank and the third one either 1%eth0 or %eth0? - Dave -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: [patch] Recent IPv6 changes in rsync/access.c
Thanks, I will apply your patch, especially since (for the record)
Hideaki posted in a reply:
> > The suggested fix Daniel Hartmeier (an OpenBSD developer) had when
> > I asked (for I'm not really a coder and I wanted to double check
> > that this was a valid problem) was making the mask[w] assignment
> > conditional like thus:
> >
> > if (w < addrlen)
> > mask[w] = 0xff & (0xff<<(8-b));
>
> Absolutely... Please apply the suggested fix.
> Thanks for finding / fixing this serious bug.
By the way, in the future I would appreciate it if you would post bugs to
the rsync mailing list instead of to me because other rsync team members
should see these things too and might be able to reply faster than me.
- Dave Dykstra
On Sat, Jan 18, 2003 at 06:21:28PM -0500, Brian Poole wrote (in private email):
> Hello,
>
> Here is a proposed patch to fix a couple problems with recent changes
> incorporated into access.c.
>
> The first is the biggest problem, there is a possible overflow
> in make_mask() if w is the same size as addrlen. Feel free to
> skip the explanation, its just there in case you don't see what
> I see.. patch is attached & at the bottom.
>
> I will walkthrough where I see the bug to have this make sense. I
> start in match_address() where I note char mask[16] at the top.
> Continuing on, we get to a switch statement for the address family;
> we imagine we take the PF_INET6 case. Two things of note here, 1st
> is addrlen = 16; 2nd is what appears to be a pasto, two copies of
>
> a = (char *)&sin6a->sin6_addr;
> t = (char *)&sin6t->sin6_addr;
>
> are found, surrounding an if statement that shouldn't affect the
> values. Thats the 2nd, minor, problem I wanted to note. I also
> moved the addrlen in my diff for cosmetic purposes. Doesn't
> matter which set of assignments is taken out.
>
> Continuing on for the bigger problem, we exit the switch statement
> and come to an if (p). Imagine p is not set and we take the else.
> This sets bits = 128.
>
> Next up is a make_mask() call with args char mask[16], 128, and 16.
> Going up to make_mask we set w = 128 >> 3, or w = 16. A few lines
> later you then have mask[w] = mask[16] is not in mask[] and
> so you have your overflow.
>
> The suggested fix Daniel Hartmeier (an OpenBSD developer) had when
> I asked (for I'm not really a coder and I wanted to double check
> that this was a valid problem) was making the mask[w] assignment
> conditional like thus:
>
> if (w < addrlen)
> mask[w] = 0xff & (0xff<<(8-b));
>
> That sounds like the correct fix to me but I shall leave it to you
> guys to finish this off. I've inlined the patch as well as attaching
> it in case you have a preference.
>
> This bug was noticed due to the propolice patches that are in
> OpenBSD-current which caused the rsync tests (which I do regularly
> for the build farm) to log messages like this:
>
> Jan 18 14:33:41 pandemonium rsync: stack overflow in function match_address
>
> I should have noticed this about 10 days ago but as this is a test
> machine I don't routinely watch the logs ;-) This gets the
> OpenBSD/sparc64 build moving along a bit further than it had been,
> though there is still one test failing (daemon-gzip-download now
> passes, daemon-gzip-upload still fails.)
>
> Will look into the other failure if I have time.
>
>
> -b
>
>
> Index: access.c
> ===
> RCS file: /cvsroot/rsync/access.c,v
> retrieving revision 1.7
> diff -u -r1.7 access.c
> --- access.c 9 Jan 2003 21:30:24 - 1.7
> +++ access.c 18 Jan 2003 23:12:57 -
> @@ -51,7 +51,8 @@
>
> if (w)
> memset(mask, 0xff, w);
> - mask[w] = 0xff & (0xff<<(8-b));
> + if (w < addrlen)
> + mask[w] = 0xff & (0xff<<(8-b));
> if (w+1 < addrlen)
> memset(mask+w+1, 0, addrlen-w-1);
>
> @@ -121,6 +122,8 @@
> a = (char *)&sin6a->sin6_addr;
> t = (char *)&sin6t->sin6_addr;
>
> + addrlen = 16;
> +
> #ifdef HAVE_SOCKADDR_IN6_SCOPE_ID
> if (sin6t->sin6_scope_id &&
> sin6a->sin6_scope_id != sin6t->sin6_scope_id) {
> @@ -128,10 +131,6 @@
> goto out;
> }
> #endif
> -
> - a = (char *)&sin6a->sin6_addr;
> - t = (char *)&sin6t->sin6_addr;
> - addrlen = 16;
>
> break;
> }
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
