Re: rsync 2.5.4 on win2k machine
D:\tmprsync -rcv *.bat \\bitserver\tmp I hate when I sent a unfinished message by accident. Anyway you can use UNC pathnames, just call them //server/dir... -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP X.509 keys available) http://www.lapo.it (ICQ UIN: 529796) -- 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: rsync 2.5.4 on win2k machine
D:\tmprsync -rcv *.bat \\bitserver\tmp First of all you should use unix-like paths and, to my knowledge, you can't use UNC paths... isn't you command line creating a directory /bitserver/tmp (or maybe /bitservertabmp) in the posix root (c:\cygwin, probably)? building file list ... done [...]test.bat read error: Connection reset by peer = i am getting read error: Connection reset by peer What version are you using 2.5.1 and 2.5.2 had such problems, but 2.5.4 is *much* better. is there any rsync setup required to make it work ? is it supposed to work with command prompt Or with ONLY cygwin ? It can work with command prompt of course, but you must use posix paths nonetheless. you can use cygpath to convert them if you want I checked /usr/doc/Cygwin rsync README file but it just tells me about compiling. i tried to compile even the latest rsync 2.5.4 source, but got following error: That's strange: 2.5.4 (as previous version) compiles out of the box with no particular library it doesn't already contains in its subdir. -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP X.509 keys available) http://www.lapo.it (ICQ UIN: 529796) -- 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: (fwd from uke@jeremy.org) thanks and patch
On Wed, Mar 20, 2002 at 03:19:37PM -0800, jeremy bornstein wrote: On Thu, Mar 21, 2002 at 10:07:14AM +1100, Martin Pool wrote: It sounds like you're using asymmetric encryption. So I suppose every time you encrypt the file, gpg will generate a new session key, so an identical cleartext file will generate a completely different cyphertext file every time. Yes, this is correct. You probably ought to use the --whole-file option of rsync then because the rolling checksums are only going to slow you down. n Wed, Mar 20, 2002 at 05:22:46PM -0800, Martin Pool wrote: On 20 Mar 2002, jeremy bornstein [EMAIL PROTECTED] wrote: Dave Dykstra wrote: Wouldn't encrypting the file with gpg change the timestamp as well as the size, so rsync would still copy the file? It certainly does--which is why I reset it afterwards. Although the backup script I use is pretty simple, having this patch to rsync does not obviate it. I actually call rsync twice--once to determine the list of files to be transferred, and once to transfer the encrypted files. In-between I do the actual encryption (and munging of the mod dates). Oh, do you mean you fiddle the mtimes of the source files to be the same as those of the destination files, and you want rsync to therefore not transfer them? Rather than going to all that trouble, why not just have your script produce an exclude file? Yes, and use --ignore-times to always transfer the files you select. - 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: zlib problem?
On Mon, Mar 18, 2002 at 07:54:01AM -0800, Victor Grey wrote: Using a fresh copy of rsync 2.5.4 installed from the ports collection on FreeBSD 4.5 Release: Works fine unless I try to copy a large file with -avz, then I get: rsync: connection unexpectedly closed (1377 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(151) Can copy the same file with -av successfully. Just wondering if this is a known problem that someone is working on. It isn't that I know of. The fact that it hangs after only 1377 bytes sounds like it's surely not a network problem. Please try to debug it further if you can; I don't have a freebsd system to try to reproduce it on, although perhaps somebody else on the mailing list would volunteer to debug it if you can find a publicly-available large file on which this happens and give precise instructions on how to duplicate it. - Dave Dykstra -- 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: zlib problem?
On Thu, Mar 21, 2002 at 09:28:05AM -0600, Dave Dykstra wrote: On Mon, Mar 18, 2002 at 07:54:01AM -0800, Victor Grey wrote: Using a fresh copy of rsync 2.5.4 installed from the ports collection on FreeBSD 4.5 Release: Works fine unless I try to copy a large file with -avz, then I get: rsync: connection unexpectedly closed (1377 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(151) Can copy the same file with -av successfully. Just wondering if this is a known problem that someone is working on. It isn't that I know of. The fact that it hangs after only 1377 bytes sounds like it's surely not a network problem. Please try to debug it further if you can; I don't have a freebsd system to try to reproduce it on, although perhaps somebody else on the mailing list would volunteer to debug it if you can find a publicly-available large file on which this happens and give precise instructions on how to duplicate it. Actually, there was a problem in 2.5.3 that could likely have had that symptom; are you sure the remote side also has 2.5.4? - Dave Dykstra -- 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: rsync 2.5.4 problem crossing file systems
I expect the problem is that you're using '*' in your script which expands
to all the directory names. Try using '.' instead.
- Dave Dykstra
On Mon, Mar 18, 2002 at 06:09:55PM -0800, [EMAIL PROTECTED] wrote:
Howdy,
I just built this new version last week and am trying to rsync a running
systems boot drive to an alternate drive on a different system (not running
on the rsync drive target). The rsync seems to be crossing file system
boundaries in spite of the -x flag. Can anyone help me with this please?
I've also submitted a bug report.
I'm running the rsync from a script that, now that I look at it, might be
confusing rsync. I've enclosed the script below.
Regards,
George...
#!/bin/sh -xv
rsync()
{
/usr/lsd/SunOS.5.7/bin/rsync -vvacrRlpogtxz --stats --progress $*
}
cd / ;rsync * 10.26.8.10:/r2.root
--exclude-from=/rsync-excludes
cd /usr ;rsync * 10.26.8.10:/r2.usr
--exclude-from=/rsync-excludes
cd /opt ;rsync * 10.26.8.10:/r2.opt
--exclude-from=/rsync-excludes
cd /var ;rsync * 10.26.8.10:/r2.var
--exclude-from=/rsync-excludes
cd /apps ;rsync * 10.26.8.10:/r2.apps
--exclude-from=/rsync-excludes
cd /export/home ;rsync * 10.26.8.10:/r2.home
--exclude-from=/rsync-excludes
exit 0
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
--
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: rsync io
On Thu, 21 Mar 2002, Jie Gao wrote: One problem I have using rsync is that if you have a large dataset, rsync will use almost all io, leaving almost none for other processes. Yup, that's particularly annoying when you use rsync for backups where it just doesn't matter if it takes one hour or twelve hours. I wonder if something can be built into rsync to make it more io-friendly so that rsync can coexist with other processes? I don't think we need to change rsync at all. Use the --rsh parameter to move the data through a program that limits the bandwidth. If you're transferring data between systems, then the bandwidth limiting program can in turn run the real ssh (or even rsh). For local transfers, it can run rsync in daemon mode. If you're running between Linux systems, and you control the kernel, and you know more than I do, then you can use QOS, to control bandwidth. Run a second ssh server on a nonstandard port, call this the slow-ssh port. Use QOS to limit the bandwidth used by traffic on that port. This will let you limit rsync to say 50% of your bandwidth, even when you've got more than one rsync process running. I have not yet configured QOS on my kernel, so I don't know the details. -- Paul Haas [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: jitterbug bug tracker ( was Re: rsync kills all user processes on fork failure)
On Tue, Mar 19, 2002 at 03:19:26PM -0800, Martin Pool wrote: On 19 Mar 2002, Paul Haas [EMAIL PROTECTED] wrote: I filed this as bug 4150 http://rsync.samba.org/cgi-bin/rsync/ Jitterbug, good, but I don't think anybody is really maintaining it at the moment. (For example, there are 733 messages in incoming.) I wonder if it would be better to just disable it and rely on the mailing list and TODO file? I stopped looking when I stopped being the official maintainer and turned the job back to Tridge, and I was wondering whether or not you were looking at it since you took over. It's definitely a terrible situation for there to be a bug tracking system with nobody looking at it, and a web page that recommends people to submit their bug reports that way. Please talk over with Tridge what to do about it. I would hope you'd be willing to maintain it. The OpenSSH project does a compromise: it's using a bug tracking system (bugzilla) but forwards all messages from the system to the developer mailing list. Project members still take the responsibility for making sure everybody gets an answer, but sometimes other list readers help out and reply for them. I'm not saying I'm recommending this for rsync, but it's an idea. I think it would really help if there were more volunteers who had write access to the rsync developer CVS to do help out where they can. I know I've asked you about a few people; have any of them been actually given access yet? The more developers there are the more reason to use a bug tracking system, I think. - 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: (fwd from uke@jeremy.org) thanks and patch
On Thu, Mar 21, 2002 at 08:39:44AM -0600, Dave Dykstra wrote: You probably ought to use the --whole-file option of rsync then because the rolling checksums are only going to slow you down. Ah, thanks! Oh, do you mean you fiddle the mtimes of the source files to be the same as those of the destination files, and you want rsync to therefore not transfer them? Rather than going to all that trouble, why not just have your script produce an exclude file? No, that isn't it. (Btw I don't seem to have received the original mail from Martin, only Dave's quoted version of it.) After determining the list of files to transfer with the patched rsync, based on mod dates, I encrypt each modified file and set the encrypted file's mod date to match the mod date of the *local* file. Yes, and use --ignore-times to always transfer the files you select. This isn't necessary. Only files to be transferred are encrypted, and the encrypted files are placed in a directory all their own--a different directory than where the original source files are. Thus the second time I call rsync--when the actual transfers are performed--rsync only sees the files which have already been encrypted and which are intended for transfer. It's only necessary to ensure that rsync doesn't delete files absent in the source tree--which is fine with me since the dest tree is a backup, after all. It seems that I must be explaining this terribly--I apologize! -j -- 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: (fwd from uke@jeremy.org) thanks and patch
On Thu, Mar 21, 2002 at 11:24:07AM -0600, Dave Dykstra wrote: Oh, I see, you want to use your new --date-only option on the first pass when you're determining which files to transfer, before you encrypt them. Yes! I guess that makes sense; I can't think of another easy to do what you want to do. Pretty obscure case though. Obscure now, but I expect not forever. If you consider it desirable for rsync to be able to do this task (encrypted backups on untrusted servers) all by itself, all it needs in addition to the --date-only option is the ability to accept a user-specified filter for each file to be transferred. If I were to make a patch for that, I don't suppose you'd want it? It'd still need an encrypting filter, but that's essentially a one line sample that could be included in the docs. (For symmetric encryption anyway.) -j -- 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: map_ptr warning
That should have been fixed in 2.5.3, are you sure you upgraded both sides? Unfortunately, 2.5.3 introduced a core dump in -z, which was fixed in 2.5.4 so you should upgrade again. More unfortunately, we just discovered that 2.5.3 also introduced a bug which turns off the rsync rolling checksum algorithm under some circumstances and that has not yet been fixed in a released version. - Dave Dykstra On Wed, Mar 20, 2002 at 10:29:11AM -0800, Jennifer Lu wrote: Hi, I compiled 2.5.3 rsync and used rsync between Solaris5.5.1 to Solaris5.8 without any error last week, then, we ran rsync on another two Solaris5.5.1 and Solaris5.8 machines, got errors: gopher# nohup timex rsync -avSHc --delete /export/mdisk14/cafe-regres/ nile-ha1:/global/dg01/vmdisk009/-regres/ building file list ... ERROR: out of memory in map_ptr rsync error: error allocating core memory buffers (code 22) at util.c(232) real22:07.59 user 9:58.00 sys 1:04.69 Can you please help? I just upgraded rsync from 2.5.2 to 2.5.3, do I need to upgrade it again? Thanks for any help. Jennifer -- 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: map_ptr warning
Hi Dave, Thanks for the reply. Yes, both servers are running rsync2.5.3, and you were correct, without -z and c, rsync ran successfully. I will tell users not using -c and z between 551 and 58. Thanks, Jennifer Date: Thu, 21 Mar 2002 11:53:57 -0600 From: Dave Dykstra [EMAIL PROTECTED] To: Jennifer Lu [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: map_ptr warning Mail-Followup-To: Dave Dykstra [EMAIL PROTECTED], Jennifer Lu [EMAIL PROTECTED], [EMAIL PROTECTED] Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.3.27i That should have been fixed in 2.5.3, are you sure you upgraded both sides? Unfortunately, 2.5.3 introduced a core dump in -z, which was fixed in 2.5.4 so you should upgrade again. More unfortunately, we just discovered that 2.5.3 also introduced a bug which turns off the rsync rolling checksum algorithm under some circumstances and that has not yet been fixed in a released version. - Dave Dykstra On Wed, Mar 20, 2002 at 10:29:11AM -0800, Jennifer Lu wrote: Hi, I compiled 2.5.3 rsync and used rsync between Solaris5.5.1 to Solaris5.8 without any error last week, then, we ran rsync on another two Solaris5.5.1 and Solaris5.8 machines, got errors: gopher# nohup timex rsync -avSHc --delete /export/mdisk14/cafe-regres/ nile-ha1:/global/dg01/vmdisk009/-regres/ building file list ... ERROR: out of memory in map_ptr rsync error: error allocating core memory buffers (code 22) at util.c(232) real22:07.59 user 9:58.00 sys 1:04.69 Can you please help? I just upgraded rsync from 2.5.2 to 2.5.3, do I need to upgrade it again? Thanks for any help. Jennifer Jennifer -- 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: map_ptr warning
I'm having a hard time believing that you're seeing the map_ptr problem in 2.5.3. Nobody else has reported that, and it was specifically fixed for that version. What's the output of rsh nile-ha1 rsync --version I'm asking you to run it that way because it's possible you have more than one installed, and if you rlogin you'll have a different PATH than if you're using rsh. -c doesn't have anything to do with it, and neither does the operating system version. By the way, -c is almost always a bad idea to put into a script because it has a lot of overhead. It's mostly useful for special one-time operations to get two directories in sync that hadn't previously been maintained by rsync. - Dave Dykstra On Thu, Mar 21, 2002 at 09:58:23AM -0800, Jennifer Lu wrote: Hi Dave, Thanks for the reply. Yes, both servers are running rsync2.5.3, and you were correct, without -z and c, rsync ran successfully. I will tell users not using -c and z between 551 and 58. Thanks, Jennifer Date: Thu, 21 Mar 2002 11:53:57 -0600 From: Dave Dykstra [EMAIL PROTECTED] To: Jennifer Lu [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: map_ptr warning Mail-Followup-To: Dave Dykstra [EMAIL PROTECTED], Jennifer Lu [EMAIL PROTECTED], [EMAIL PROTECTED] Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.3.27i That should have been fixed in 2.5.3, are you sure you upgraded both sides? Unfortunately, 2.5.3 introduced a core dump in -z, which was fixed in 2.5.4 so you should upgrade again. More unfortunately, we just discovered that 2.5.3 also introduced a bug which turns off the rsync rolling checksum algorithm under some circumstances and that has not yet been fixed in a released version. - Dave Dykstra On Wed, Mar 20, 2002 at 10:29:11AM -0800, Jennifer Lu wrote: Hi, I compiled 2.5.3 rsync and used rsync between Solaris5.5.1 to Solaris5.8 without any error last week, then, we ran rsync on another two Solaris5.5.1 and Solaris5.8 machines, got errors: gopher# nohup timex rsync -avSHc --delete /export/mdisk14/cafe-regres/ nile-ha1:/global/dg01/vmdisk009/-regres/ building file list ... ERROR: out of memory in map_ptr rsync error: error allocating core memory buffers (code 22) at util.c(232) real22:07.59 user 9:58.00 sys 1:04.69 Can you please help? I just upgraded rsync from 2.5.2 to 2.5.3, do I need to upgrade it again? Thanks for any help. Jennifer Jennifer -- 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: include exclude help please.
Dave Dykstra([EMAIL PROTECTED])@Thu, Mar 21, 2002 at 10:17:46AM -0600: Let me explain Wayne's answer a little further. The main thing you need to understand is that the exclude algorithm is applied recursively so any time there's an exclude that matches a directory, rsync will not descend any further so if you're using --exclude '*' you need to include all directories above what you want to copy. Also, the basename of the source directory is included in the patterns if the source directory doesn't end with a slash. This would be the straightforward answer: rsync -avv --include /film/ --include /film/jonah/ \ --include /film/jonah/**/ --include /film/jonah/**/sourceimages/ \ --include /film/jonah/**/sourceimages/*.tif --exclude * /film /tmp thanks. this worked (almost): rsync -avv --include /film/ --include /film/jonah/ \ --include /film/jonah/**/ --include /film/jonah/**/sourceimages/ \ --include /film/jonah/**/sourceimages/*.tif --exclude * /film /tmp it got all the tiff that were located in a directory somewhere under /film/jonah named sourceimages. but for some reason it also picked up these: find ./ -iname \*.tif | grep -v sourceimages ./dept/concept/CHUCK_VOLLMER/hard drive/Documents/.Chuck's In Progress/jonah/master_paintings/treeflats/openingshothill.tif ./dept/concept/CHUCK_VOLLMER/treeflats/openingshothill.tif ./dept/concept/JOE_SAPULICH/Ship Hold Final.tif ./dept/concept/JOE_SAPULICH/ad tiffs/Location6_PirateShip/Sets/final_Pirate_ship ext.tif ./dept/concept/JOE_SAPULICH/ad tiffs/Ship Hold Final.tif ./dept/concept/JOE_SAPULICH/ad tiffs/joppa_tent_final.tif ./dept/concept/JOE_SAPULICH/final_pirate_ship_ext.tif ./dept/concept/findByContent/Approved_Ebinder/Location6_PirateShip/Sets/final_Pirate_ship ext.tif ./dept/lighting/dan/renderData/iprImages/rest8.tif Ah, this is probably the best way to go, but you need a trailing slash on the end of each of the directories or else the sourceimages is going to get excluded by the --exclude '*'. Try piping the find through sed 's,$,/,' rsync -rvv --relative --include='*.tif' --exclude='/*' `find /film/jonah -type d -name sourceimages -print | sed 's,$,/,' ` /tmp almost worked but for some reason picked up everything under the sourecimages directories. I too can't wait to see Jonah. My kids have seen all the Veggie Tales and 3-2-1 Penguin videos. Also, I live in the Chicago area and have run into a guy in my hometown's new library a couple times who told me he works on Penguin 3. I'm delighted to know that rsync is helping Big Idea. Wonderful! You should run out and buy the new Larryboy video that came out Tuesday. It is 2D and animated in/with Flash. Thanks for all your help, joe -- 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: include exclude help please.
On Thu, Mar 21, 2002 at 03:24:39PM -0600, Joe Rice wrote: Dave Dykstra([EMAIL PROTECTED])@Thu, Mar 21, 2002 at 10:17:46AM -0600: Let me explain Wayne's answer a little further. The main thing you need to understand is that the exclude algorithm is applied recursively so any time there's an exclude that matches a directory, rsync will not descend any further so if you're using --exclude '*' you need to include all directories above what you want to copy. Also, the basename of the source directory is included in the patterns if the source directory doesn't end with a slash. This would be the straightforward answer: rsync -avv --include /film/ --include /film/jonah/ \ --include /film/jonah/**/ --include /film/jonah/**/sourceimages/ \ --include /film/jonah/**/sourceimages/*.tif --exclude * /film /tmp thanks. this worked (almost): rsync -avv --include /film/ --include /film/jonah/ \ --include /film/jonah/**/ --include /film/jonah/**/sourceimages/ \ --include /film/jonah/**/sourceimages/*.tif --exclude * /film /tmp it got all the tiff that were located in a directory somewhere under /film/jonah named sourceimages. but for some reason it also picked up these: find ./ -iname \*.tif | grep -v sourceimages ./dept/concept/CHUCK_VOLLMER/hard drive/Documents/.Chuck's In Progress/jonah/master_paintings/treeflats/openingshothill.tif ./dept/concept/CHUCK_VOLLMER/treeflats/openingshothill.tif ./dept/concept/JOE_SAPULICH/Ship Hold Final.tif ./dept/concept/JOE_SAPULICH/ad tiffs/Location6_PirateShip/Sets/final_Pirate_ship ext.tif ./dept/concept/JOE_SAPULICH/ad tiffs/Ship Hold Final.tif ./dept/concept/JOE_SAPULICH/ad tiffs/joppa_tent_final.tif ./dept/concept/JOE_SAPULICH/final_pirate_ship_ext.tif ./dept/concept/findByContent/Approved_Ebinder/Location6_PirateShip/Sets/final_Pirate_ship ext.tif ./dept/lighting/dan/renderData/iprImages/rest8.tif Very strange. I don't know what to tell you. Are you sure those weren't copied by another command? I just remembered that -vv now reports very useful information about what includes/excludes are doing. Try using that to see what's going on. Ah, this is probably the best way to go, but you need a trailing slash on the end of each of the directories or else the sourceimages is going to get excluded by the --exclude '*'. Try piping the find through sed 's,$,/,' rsync -rvv --relative --include='*.tif' --exclude='/*' `find /film/jonah -type d -name sourceimages -print | sed 's,$,/,' ` /tmp almost worked but for some reason picked up everything under the sourecimages directories. Oh, sorry, exclude patterns with --relative are the whole name so you the --exclude '/*' isn't right. It should be --exclude '*'. Unfortunately, I just tried that on a test case and it too had a problem. -vv revealed that with --relative and --exclude '*' you also need a --include '.'. Very non-intuitive indeed, I expect it should be fixed. I vaguely recall running into this once before. - 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: Anonymous rsync server on LAN
Sounds like you want to do something like this: http://killyridols.net/rsyncssh.shtml -Dan Young I really want to use the anonymous rsync method so as to avoid having to type in the password manually, so that I can automate this with a cron script. -- 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: map_ptr warning
Dave, Yes, both machines are in the same version, here is the output: On Solaris5.8: nile-ha1 %rsh nile-ha1 rsync --version rsync version 2.5.3 protocol version 26 Copyright (C) 1996-2002 by Andrew Tridgell and others http://rsync.samba.org/ Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles, no IPv6,64-bit system inums, 64-bit internal inums On Solaris 5.5.1: 64-bit system inums, 64-bit internal inums % rsh gopher rsync --version rsync version 2.5.3 protocol version 26 Copyright (C) 1996-2002 by Andrew Tridgell and others http://rsync.samba.org/ Capabilities: 32-bit files, socketpairs, hard links, symlinks, batchfiles, no IPv6,32-bit system inums, 64-bit internal inums I ran rsync -avSH --delete gopher:/export/mdisk14/cafe-regres/ /global/dg01/vmdisk009/cafe-regres/, it went successfully. Only with -avzSHc option, rsync failed with map_ptr warning. Thanks for the help, Jennifer Date: Thu, 21 Mar 2002 12:56:47 -0600 From: Dave Dykstra [EMAIL PROTECTED] To: Jennifer Lu [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: map_ptr warning Mail-Followup-To: Dave Dykstra [EMAIL PROTECTED], Jennifer Lu [EMAIL PROTECTED], [EMAIL PROTECTED] Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.3.27i I'm having a hard time believing that you're seeing the map_ptr problem in 2.5.3. Nobody else has reported that, and it was specifically fixed for that version. What's the output of rsh nile-ha1 rsync --version I'm asking you to run it that way because it's possible you have more than one installed, and if you rlogin you'll have a different PATH than if you're using rsh. -c doesn't have anything to do with it, and neither does the operating system version. By the way, -c is almost always a bad idea to put into a script because it has a lot of overhead. It's mostly useful for special one-time operations to get two directories in sync that hadn't previously been maintained by rsync. - Dave Dykstra On Thu, Mar 21, 2002 at 09:58:23AM -0800, Jennifer Lu wrote: Hi Dave, Thanks for the reply. Yes, both servers are running rsync2.5.3, and you were correct, without -z and c, rsync ran successfully. I will tell users not using -c and z between 551 and 58. Thanks, Jennifer Date: Thu, 21 Mar 2002 11:53:57 -0600 From: Dave Dykstra [EMAIL PROTECTED] To: Jennifer Lu [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: map_ptr warning Mail-Followup-To: Dave Dykstra [EMAIL PROTECTED], Jennifer Lu [EMAIL PROTECTED], [EMAIL PROTECTED] Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.3.27i That should have been fixed in 2.5.3, are you sure you upgraded both sides? Unfortunately, 2.5.3 introduced a core dump in -z, which was fixed in 2.5.4 so you should upgrade again. More unfortunately, we just discovered that 2.5.3 also introduced a bug which turns off the rsync rolling checksum algorithm under some circumstances and that has not yet been fixed in a released version. - Dave Dykstra On Wed, Mar 20, 2002 at 10:29:11AM -0800, Jennifer Lu wrote: Hi, I compiled 2.5.3 rsync and used rsync between Solaris5.5.1 to Solaris5.8 without any error last week, then, we ran rsync on another two Solaris5.5.1 and Solaris5.8 machines, got errors: gopher# nohup timex rsync -avSHc --delete /export/mdisk14/cafe-regres/ nile-ha1:/global/dg01/vmdisk009/-regres/ building file list ... ERROR: out of memory in map_ptr rsync error: error allocating core memory buffers (code 22) at util.c(232) real22:07.59 user 9:58.00 sys 1:04.69 Can you please help? I just upgraded rsync from 2.5.2 to 2.5.3, do I need to upgrade it again? Thanks for any help. Jennifer Jennifer Jennifer -- 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: Bug in compile of rsync 2.5.4 on Tru64 UNIX V5.1a using cc
Hi Eckert,
On Thu, Mar 21, 2002 at 03:15:39PM -0500, Eckert, Robert D wrote:
Greetings, here is the output of the 'configure' step and
the compile step (using the Compaq cc compiler that comes
with Tru64 V5.1A. The configure reported success and most of
the compile steps cam through error/warning free except for
the one that stumbled. Can someone help me out here? I am willing
to provide a binary for Tru64 V5.1A if we can swat this bug.
I had the same problem. I managed to have rsync compiled OK on my
Tru64 5.1 box with helps from couple of people from this list.
Try with the patch I attach here.
I am not a C programmer so you'd better check to make sure it is
correct.
We depend greatly on Rsync to keep a fresh backup of our
70gb storage system that is the backend of http://www.indiana.edu/,
Indiana University's main web site to the Internet.
I plan to do the same here instead of Tru64 vdump and vrestore
once I am sure backups by rsync is as reliable as vdump/vrestore.
Do you use rsync for root, usr partitions and and database files?
Have you had any problem with rsync so far?
Cheers,
--
Zoong Pham[EMAIL PROTECTED]
UNIX Systems AdministratorMercy Health and Aged Care Inc.
To get my PGP public key, email me with the subject:
Request for Zoong Pham's PGP public key
diff -u -r rsync-2.5.4/batch.c rsync-2.5.4.new/batch.c
--- rsync-2.5.4/batch.c Thu Feb 7 08:20:48 2002
+++ rsync-2.5.4.new/batch.c Fri Mar 22 09:24:01 2002
@@ -405,7 +405,15 @@
/* FIXME: This will break if s-count is ever not exactly an int. */
write_batch_csums_file(flist_entry, sizeof(int));
+ if (s) {
+ write_batch_csums_file(s-count, sizeof(int));
+ }
+ else if (!s) {
+ write_batch_csums_file(int_zero, sizeof(int));
+ }
+ /*
write_batch_csums_file(s ? s-count : int_zero, sizeof(int));
+ */
if (s) {
for (i = 0; i s-count; i++) {
diff -u -r rsync-2.5.4/config.h.in rsync-2.5.4.new/config.h.in
--- rsync-2.5.4/config.h.in Thu Feb 28 10:15:55 2002
+++ rsync-2.5.4.new/config.h.in Fri Mar 22 09:24:01 2002
@@ -140,6 +140,9 @@
/* Define if you have the `mknod' function. */
#undef HAVE_MKNOD
+/* Define if you have the `mkfifo' function. */
+#undef HAVE_MKFIFO
+
/* Define if you have the `mtrace' function. */
#undef HAVE_MTRACE
@@ -244,6 +247,9 @@
/* Define if you have the sys/socket.h header file. */
#undef HAVE_SYS_SOCKET_H
+
+/* Define if you have the sys/un.h header file. */
+#undef HAVE_SYS_UN_H
/* Define if you have the sys/stat.h header file. */
#undef HAVE_SYS_STAT_H
diff -u -r rsync-2.5.4/configure rsync-2.5.4.new/configure
--- rsync-2.5.4/configure Wed Mar 13 11:03:50 2002
+++ rsync-2.5.4.new/configure Fri Mar 22 09:24:01 2002
@@ -3414,7 +3414,7 @@
fi
done
-for ac_header in sys/filio.h string.h stdlib.h sys/socket.h sys/mode.h
+for ac_header in sys/filio.h string.h stdlib.h sys/socket.h sys/mode.h sys/un.h
do
as_ac_Header=`echo ac_cv_header_$ac_header | $as_tr_sh`
echo $as_me:3420: checking for $ac_header 5
@@ -6165,7 +6165,7 @@
fi
rm -f conftest.data
-for ac_func in waitpid wait4 getcwd strdup strerror chown chmod mknod
+for ac_func in waitpid wait4 getcwd strdup strerror chown chmod mknod mkfifo
do
as_ac_var=`echo ac_cv_func_$ac_func | $as_tr_sh`
echo $as_me:6171: checking for $ac_func 5
diff -u -r rsync-2.5.4/configure.in rsync-2.5.4.new/configure.in
--- rsync-2.5.4/configure.inWed Mar 13 11:03:34 2002
+++ rsync-2.5.4.new/configure.inFri Mar 22 09:24:01 2002
@@ -242,7 +242,7 @@
AC_HEADER_SYS_WAIT
AC_CHECK_HEADERS(sys/fcntl.h sys/select.h fcntl.h sys/time.h sys/unistd.h unistd.h
utime.h grp.h)
AC_CHECK_HEADERS(compat.h sys/param.h ctype.h sys/wait.h sys/ioctl.h)
-AC_CHECK_HEADERS(sys/filio.h string.h stdlib.h sys/socket.h sys/mode.h)
+AC_CHECK_HEADERS(sys/filio.h string.h stdlib.h sys/socket.h sys/mode.h sys/un.h)
AC_CHECK_HEADERS(glob.h alloca.h mcheck.h sys/sysctl.h arpa/inet.h arpa/nameser.h)
AC_CHECK_HEADERS(netdb.h)
AC_CHECK_HEADERS(malloc.h)
@@ -315,7 +315,19 @@
AC_CHECK_FUNCS(inet_ntop, , AC_LIBOBJ(lib/inet_ntop))
AC_CHECK_FUNCS(inet_pton, , AC_LIBOBJ(lib/inet_pton))
-AC_CHECK_FUNCS(getaddrinfo, , AC_LIBOBJ(lib/getaddrinfo))
+# Tru64 UNIX has getaddrinfo() but has it renamed in libc as
+# something else so we must include netdb.h to get the
+# redefinition.
+AC_MSG_CHECKING([for getaddrinfo])
+AC_TRY_LINK([#include sys/types.h
+#include sys/socket.h
+#include netdb.h],[getaddrinfo(NULL, NULL, NULL, NULL);],
+ [AC_MSG_RESULT([yes])
+ AC_DEFINE(HAVE_GETADDRINFO, 1,
+ [Define if you have the `getaddrinfo' function.])],
+ [AC_MSG_RESULT([no])
+ AC_LIBOBJ(lib/getaddrinfo)])
+
AC_CHECK_FUNCS(getnameinfo, , AC_LIBOBJ(lib/getnameinfo))
AC_CHECK_MEMBER([struct sockaddr.sa_len],
@@ -348,7 +360,7 @@
dnl AC_FUNC_MEMCMP
AC_FUNC_UTIME_NULL
Re: rsync io
You're obviously not the first to need this. That's why the '--bwlimit=' option was added. Set it to however many Kbps you want rsync to use. I usually use 768 going over our wan, to spare some bandwidth on the T1, and maybe 1 over the lan (in my case, all the dasd is nfs). I suspect that it may affect local-to-local transfers as well, but haven't tested it, but you can always use localhost:path to make sure. 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? Paul Haas [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 03/21/2002 08:44 AM Please respond to paulh To: [EMAIL PROTECTED] Jie Gao [EMAIL PROTECTED] cc: (bcc: Tim Conway/LMT/SC/PHILIPS) Subject:Re: rsync io Classification: On Thu, 21 Mar 2002, Jie Gao wrote: One problem I have using rsync is that if you have a large dataset, rsync will use almost all io, leaving almost none for other processes. Yup, that's particularly annoying when you use rsync for backups where it just doesn't matter if it takes one hour or twelve hours. I wonder if something can be built into rsync to make it more io-friendly so that rsync can coexist with other processes? I don't think we need to change rsync at all. Use the --rsh parameter to move the data through a program that limits the bandwidth. If you're transferring data between systems, then the bandwidth limiting program can in turn run the real ssh (or even rsh). For local transfers, it can run rsync in daemon mode. If you're running between Linux systems, and you control the kernel, and you know more than I do, then you can use QOS, to control bandwidth. Run a second ssh server on a nonstandard port, call this the slow-ssh port. Use QOS to limit the bandwidth used by traffic on that port. This will let you limit rsync to say 50% of your bandwidth, even when you've got more than one rsync process running. I have not yet configured QOS on my kernel, so I don't know the details. -- Paul Haas [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 -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
[PATCH] --link-dest option
Please CC me. I'm not subscribed.
Attached is a patch against 2.5.4pre1 CVS current to add the
--link-dest option so rsync will create hardlinks for
unchanged regular files to a directory on the destination.
This is like --compare-dest except that the result is not a
sparse tree.
Also included is extension to --(ex|in)clude-from to allow -
for stdin.
Could one of the maintainers please add this to the
mainline?
Thanks to Dave Dykstra for feedback on this.
--
J.W. SchultzPegasystems Technologies
email address: [EMAIL PROTECTED]
Remember Cernan and Schmitt
? options-merge.c
Index: exclude.c
===
RCS file: /cvsroot/rsync/exclude.c,v
retrieving revision 1.42
diff -u -r1.42 exclude.c
--- exclude.c 18 Feb 2002 19:10:28 - 1.42
+++ exclude.c 21 Mar 2002 23:31:25 -
@@ -219,8 +219,14 @@
int fatal, int include)
{
struct exclude_struct **list=list1;
- FILE *f = fopen(fname,r);
+ FILE *f;
char line[MAXPATHLEN];
+
+ if (strcmp(fname, -)) {
+ f = fopen(fname,r);
+ } else {
+ f = fdopen(0, r);
+ }
if (!f) {
if (fatal) {
rsyserr(FERROR, errno,
Index: generator.c
===
RCS file: /cvsroot/rsync/generator.c,v
retrieving revision 1.37
diff -u -r1.37 generator.c
--- generator.c 19 Mar 2002 20:16:42 - 1.37
+++ generator.c 21 Mar 2002 23:31:26 -
@@ -41,6 +41,7 @@
extern int always_checksum;
extern int modify_window;
extern char *compare_dest;
+extern int link_dest;
/* choose whether to skip a particular file */
@@ -50,6 +51,15 @@
if (st-st_size != file-length) {
return 0;
}
+ if (link_dest) {
+ if((st-st_mode ~_S_IFMT) != (file-mode ~_S_IFMT)) {
+ return 0;
+ }
+ if (st-st_uid != file-uid || st-st_gid != file-gid) {
+ return 0;
+ }
+ }
+
/* if always checksum is set then we use the checksum instead
of the file time to determine whether to sync */
@@ -382,6 +392,17 @@
statret = -1;
if (statret == -1)
errno = saveerrno;
+#if HAVE_LINK
+ else if (link_dest)
+ if (do_link(fnamecmpbuf, fname) != 0) {
+ if (verbose 0)
+ rprintf(FINFO,link %s = %s : %s\n,
+ fnamecmpbuf,
+ fname,
+ strerror(errno));
+ fnamecmp = fnamecmpbuf;
+ }
+#endif
else
fnamecmp = fnamecmpbuf;
}
Index: options.c
===
RCS file: /cvsroot/rsync/options.c,v
retrieving revision 1.89
diff -u -r1.89 options.c
--- options.c 19 Mar 2002 20:16:42 - 1.89
+++ options.c 21 Mar 2002 23:31:27 -
@@ -113,6 +113,7 @@
char *rsync_path = RSYNC_PATH;
char *backup_dir = NULL;
int rsync_port = RSYNC_PORT;
+int link_dest = 0;
int verbose = 0;
int quiet = 0;
@@ -282,7 +283,7 @@
OPT_EXCLUDE_FROM, OPT_DELETE, OPT_DELETE_EXCLUDED, OPT_NUMERIC_IDS,
OPT_RSYNC_PATH, OPT_FORCE, OPT_TIMEOUT, OPT_DAEMON, OPT_CONFIG, OPT_PORT,
OPT_INCLUDE, OPT_INCLUDE_FROM, OPT_STATS, OPT_PARTIAL, OPT_PROGRESS,
- OPT_COPY_UNSAFE_LINKS, OPT_SAFE_LINKS, OPT_COMPARE_DEST,
+ OPT_COPY_UNSAFE_LINKS, OPT_SAFE_LINKS, OPT_COMPARE_DEST, OPT_LINK_DEST,
OPT_LOG_FORMAT, OPT_PASSWORD_FILE, OPT_SIZE_ONLY, OPT_ADDRESS,
OPT_DELETE_AFTER, OPT_EXISTING, OPT_MAX_DELETE, OPT_BACKUP_DIR,
OPT_IGNORE_ERRORS, OPT_BWLIMIT, OPT_BLOCKING_IO,
@@ -341,6 +342,7 @@
{timeout, 0, POPT_ARG_INT,io_timeout , 0, 0, 0 },
{temp-dir,'T', POPT_ARG_STRING, tmpdir , 0, 0, 0 },
{compare-dest, 0, POPT_ARG_STRING, compare_dest , 0, 0, 0 },
+ {link-dest,0, POPT_ARG_STRING, 0, OPT_LINK_DEST, 0, 0 },
/* TODO: Should this take an optional int giving the compression level? */
{compress,'z', POPT_ARG_NONE, do_compression , 0, 0, 0 },
{daemon, 0, POPT_ARG_NONE, am_daemon , 0, 0, 0 },
@@ -562,6 +564,19 @@
/* popt stores the filename in batch_prefix for us */
read_batch = 1;
break;
+ case OPT_LINK_DEST:
+#if HAVE_LINK
+ compare_dest = poptGetOptArg(pc);
+ link_dest = 1;
+ break;
+#else
+
Re: (fwd from uke@jeremy.org) thanks and patch
On Thu, Mar 21, 2002 at 09:42:21AM -0800, jeremy bornstein wrote: On Thu, Mar 21, 2002 at 11:24:07AM -0600, Dave Dykstra wrote: Oh, I see, you want to use your new --date-only option on the first pass when you're determining which files to transfer, before you encrypt them. Yes! I guess that makes sense; I can't think of another easy to do what you want to do. Pretty obscure case though. Obscure now, but I expect not forever. If you consider it desirable for rsync to be able to do this task (encrypted backups on untrusted servers) all by itself, all it needs in addition to the --date-only option is the ability to accept a user-specified filter for each file to be transferred. If I were to make a patch for that, I don't suppose you'd want it? I don't know, I think it would depend on the implementation. There might be a number of uses that people could put it to. The thing that I don't like about it is that for most uses I can think of (compression is another example) it won't be able to use the rsync rolling checksum algorithm, which is mostly what people think of when they think of rsync. It's true that a lot of people end up using rsync just for its ability to recurse down two directory structures and identify differences, however, so they might be happy with it. I would think the option would default to --no-whole-file and imply your --date-only functionality even if we don't have the option. (If we did want --date-only functionality as a separate option I think it should be called --times-only to go along with --ignore-times). It'd still need an encrypting filter, but that's essentially a one line sample that could be included in the docs. (For symmetric encryption anyway.) - 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
Bug in compile of rsync 2.5.4 on Tru64 UNIX V5.1a using cc
Greetings, here is the output of the 'configure' step and the compile step (using the Compaq cc compiler that comes with Tru64 V5.1A. The configure reported success and most of the compile steps cam through error/warning free except for the one that stumbled. Can someone help me out here? I am willing to provide a binary for Tru64 V5.1A if we can swat this bug. We depend greatly on Rsync to keep a fresh backup of our 70gb storage system that is the backend of http://www.indiana.edu/, Indiana University's main web site to the Internet. We're also big fans and soon to be BIG adopters of Samba 2.2.3a. Anyway here is the sequence that was encountered: [root@hyperion: rsync-2.5.4]#CC=cc ; export CC ; ./configure configure: Configuring rsync 2.5.4 checking build system type... alphaev5-dec-osf5.1 checking host system type... alphaev5-dec-osf5.1 checking target system type... alphaev5-dec-osf5.1 checking for gcc... cc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for executable suffix... checking for object suffix... o checking whether we are using the GNU C compiler... no checking whether cc accepts -g... yes checking how to run the C preprocessor... cc -E checking for a BSD compatible install... ./install-sh -c checking for cc option to accept ANSI C... none needed checking whether to include debugging symbols... yes checking for remsh... 0 checking for broken largefile support... no checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking for _LARGE_FILES value needed for large files... no checking ipv6 stack type... unknown checking for library containing getaddrinfo... no checking whether byte ordering is bigendian... no checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking whether time.h and sys/time.h may both be included... yes checking for sys/wait.h that is POSIX.1 compatible... yes checking for sys/fcntl.h... yes checking for sys/select.h... yes checking for fcntl.h... yes checking for sys/time.h... yes checking for sys/unistd.h... no checking for unistd.h... yes checking for utime.h... yes checking for grp.h... yes checking for compat.h... no checking for sys/param.h... yes checking for ctype.h... yes checking for sys/wait.h... (cached) yes checking for sys/ioctl.h... yes checking for sys/filio.h... no checking for string.h... yes checking for stdlib.h... yes checking for sys/socket.h... yes checking for sys/mode.h... yes checking for glob.h... yes checking for alloca.h... yes checking for mcheck.h... no checking for sys/sysctl.h... no checking for arpa/inet.h... yes checking for arpa/nameser.h... yes checking for netdb.h... yes checking for malloc.h... yes checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... (cached) yes checking for int... yes checking size of int... 4 checking for long... yes checking size of long... 8 checking for short... yes checking size of short... 2 checking for inline... inline checking return type of signal handlers... void checking for uid_t in sys/types.h... yes checking for mode_t... yes checking for off_t... yes checking for size_t... yes checking for pid_t... yes checking type of array argument to getgroups... gid_t checking for struct stat.st_rdev... yes checking for ino_t... yes checking for socklen_t... no checking for socklen_t equivalent... int checking for errno in errno.h... yes checking for connect... yes checking for inet_ntop in -lresolv... yes checking for inet_ntop... yes checking for inet_pton... yes checking for getaddrinfo... no checking for getnameinfo... yes checking for struct sockaddr.sa_len... no checking struct sockaddr_storage... yes checking for strcasecmp... yes checking whether utime accepts a null argument... yes checking for waitpid... yes checking for wait4... yes checking for getcwd... yes checking for strdup... yes checking for strerror... yes checking for chown... yes checking for chmod... yes checking for mknod... yes checking for fchmod... yes checking for fstat... yes checking for strchr... yes checking for readlink... yes checking for link... yes checking for utime... yes checking for utimes... yes checking for strftime... yes checking for memmove... yes checking for lchown... yes checking for vsnprintf... yes checking for snprintf... yes checking for asprintf... no checking for setsid... yes checking for glob... yes checking for strpbrk... yes checking for strlcat... no checking for strlcpy... no checking for mtrace... no checking for mallinfo... yes checking for setgroups... yes checking for working socketpair... yes checking for working
Re: Bug in compile of rsync 2.5.4 on Tru64 UNIX V5.1a using cc
On Thu, 21 Mar 2002, Eckert, Robert D wrote:
Greetings, here is the output of the 'configure' step and
the compile step (using the Compaq cc compiler that comes
with Tru64 V5.1A. The configure reported success and most of
the compile steps cam through error/warning free except for
the one that stumbled. Can someone help me out here? I am willing
to provide a binary for Tru64 V5.1A if we can swat this bug.
We depend greatly on Rsync to keep a fresh backup of our
70gb storage system that is the backend of http://www.indiana.edu/,
Indiana University's main web site to the Internet. We're also big
fans and soon to be BIG adopters of Samba 2.2.3a.
Anyway here is the sequence that was encountered:
cc -I. -I. -g -DHAVE_CONFIG_H -I./popt -c batch.c -o batch.o
cc: Error: batch.c, line 408: In this statement, a common type could not be
determined for the 2nd and 3rd operands (s-count and int_zero) of a
conditional operator. (badcondit)
write_batch_csums_file(s ? s-count : int_zero, sizeof(int));
---^
*** Exit 1
Line 406 says:
/* FIXME: This will break if s-count is ever not exactly an int. */
s-count is a size_t, which is 64 bits on your compiler.
Here's how I would fix it:
===
RCS file: RCS/batch.c,v
retrieving revision 1.1
diff -u -r1.1 batch.c
--- batch.c 2002/03/21 21:31:52 1.1
+++ batch.c 2002/03/21 21:44:11
-396,16 +396,17
struct sum_struct *s)
{
size_t i;
- unsigned int int_zero = 0;
+ unsigned int int_count;
extern int csum_length;
fdb_open = 1;
/* Write csum info to batch file */
- /* FIXME: This will break if s-count is ever not exactly an int. */
+ /* FIXME: This will break if s-count is ever greater than 2^32 -1 */
write_batch_csums_file(flist_entry, sizeof(int));
- write_batch_csums_file(s ? s-count : int_zero, sizeof(int));
+ int_count = s ? (unsigned int) s-count : 0;
+ write_batch_csums_file(int_count, sizeof(int_count));
if (s) {
for (i = 0; i s-count; i++) {
--
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: Bug in compile of rsync 2.5.4 on Tru64 UNIX V5.1a using cc
On Thu, Mar 21, 2002 at 04:45:53PM -0500, Paul Haas wrote: Here's how I would fix it: See patches/jos-solaris-sizet.diff for my fix. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- 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: Anonymous rsync server on LAN
On 21 Mar 2002, Berend Tober [EMAIL PROTECTED] wrote: uid = nobody gid = nobody use chroot = yes read only=yes max connections = 2 log file = /var/log/rsyncd.log hosts allow = 192.168.123.3 hosts deny = *.*.*.* [home] path=/home [samba] path=/var/local/samba Try taking out the hosts deny line. -- Martin -- 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] --link-dest option
On 21 Mar 2002, jw schultz [EMAIL PROTECTED] wrote: Please CC me. I'm not subscribed. Attached is a patch against 2.5.4pre1 CVS current to add the --link-dest option so rsync will create hardlinks for unchanged regular files to a directory on the destination. This is like --compare-dest except that the result is not a sparse tree. That's really good, thankyou. I think we should merge this, but not right now because we need to stabilize 2.5. I will put it in the patches/ directory. Also included is extension to --(ex|in)clude-from to allow - for stdin. It's somewhat better if you send each patch in a separate email, in case people want to merge one but not the other. Of course in this case it's pretty trivial to split them, and I don't see any reason not to take both. If you have time, it would be really excellent if you could write a test case for the new features, based on the existing ones in testsuite/ Thanks, -- Martin -- 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] --link-dest option
On Thu, Mar 21, 2002 at 07:44:34PM -0800, Martin Pool wrote: On 21 Mar 2002, jw schultz [EMAIL PROTECTED] wrote: Please CC me. I'm not subscribed. Attached is a patch against 2.5.4pre1 CVS current to add the --link-dest option so rsync will create hardlinks for unchanged regular files to a directory on the destination. This is like --compare-dest except that the result is not a sparse tree. That's really good, thankyou. I think we should merge this, but not right now because we need to stabilize 2.5. I will put it in the patches/ directory. Understood. The POPT stuff at least is a moving target. My primary concern is that at some point i can say use version x.y or greater Also included is extension to --(ex|in)clude-from to allow - for stdin. It's somewhat better if you send each patch in a separate email, in case people want to merge one but not the other. Of course in this case it's pretty trivial to split them, and I don't see any reason not to take both. Generally, i agree. The stdin stuff was more like a crumb. Trivial to isolate but so obviously corect. If you have time, it would be really excellent if you could write a test case for the new features, based on the existing ones in testsuite/ Thanks, -- Martin I'm looking at testsuite now. A regression test is desireable, especially to make sure that the linked from tree doesn't get modified. With checkit and the surrounding complexity it is no wonder --compare-dest doesn't have a test case either. I'll make no promises. -- 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
