Re: -b --suffix '' --delete --backup-dir /path/ combination doesnot act as expected
[I apparently lost some of my email that was sent to my samba.org address due to some bogus spam filtering involving my use of spamcop.org (which I just turned off). I looked up your reply in a mailing list archive on the web...] My only concern is that i don't like depending on strcmp(backup_suffix, BACKUP_SUFFIX). The new test is more complex than that (you cited the old test). The new test ensures that we send the suffix value if it differs from the default suffix value. The 3 examples you listed are how the new code behaves. I don't care for deleting here either I've thought about it some more, and I think it's actually correct. The backing up of the files is something that is occurring for both changed and deleted files, so we should mention the files that are deleted in the same way they would be mentioned if --backup wasn't specified. I wouldn't want to see the backup messages moved from verbose level 2 to level 1 because they would be very redundant (since everything that gets changed or deleted gets backed up). I tweaked my code just a bit more and went ahead and checked it into CVS. If there are still areas of contention, we can hash them out and check in changes, as needed. ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: -b --suffix '' --delete --backup-dir /path/ combination doesnot act as expected
On Fri, Aug 01, 2003 at 01:21:53AM -0700, Wayne Davison wrote:
[I apparently lost some of my email that was sent to my samba.org
address due to some bogus spam filtering involving my use of spamcop.org
(which I just turned off). I looked up your reply in a mailing list
archive on the web...]
My only concern is that i don't like depending on
strcmp(backup_suffix, BACKUP_SUFFIX).
The new test is more complex than that (you cited the old test). The
new test ensures that we send the suffix value if it differs from the
default suffix value. The 3 examples you listed are how the new code
behaves.
If for some reason they specify
--suffix=~ --backup-dir=../foo
it should create the backup files with the requested suffix.
It looks like it will behave that way for a pull but not a
push.
In options.c
if (!backup_suffix)
backup_suffix = backup_dir ? : BACKUP_SUFFIX;
gets it right but
/* Only send --suffix if it specifies a non-default * value. */
if (strcmp(backup_suffix, backup_dir? : BACKUP_SUFFIX) != 0) {
args[ac++] = --suffix;
args[ac++] = backup_suffix;
}
doesn't. We want to send the suffix if they specified one
even if they specified the default. Otherwise we get
inconsistant behavior.
Sorry to pick nits but this is the kind of inconsistancy
that annoys me. I ran into the same kind of behavior with
--block-size when i was working on the dynamic checksum
lenghts. The earlier dynamic block size code made it
impossible to force a fixed 700 byte block size because that
had been the default.
--
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.catb.org/~esr/faqs/smart-questions.html
Weird hanging problem with rsync
Hi! I have a weird problem I can't quite grasp. I rsync machines directories to a central machine and backup from there to tape. So far so fine. But I have weird hangings with rsync doing nothing whatsoever on some files. If this situation arises, rsync won't go on with processing, won't actually work on something (CPU is quite low in those situations) and will only send packages over the wire very seldom - maybe once a minute or so. This most often happens with logfiles like the syslog or the daemon.log - files that are bound to change while they are rsynced. It happened with other files, too, but those were allmost always active files or files in active directories where current accesses change files. So my questions is, is rsync actually capable of rsyncing files that change while they are rsynced? Or if not, are there any tips on preventing this weird hanging problem? I use rsync versions 2.3 on debian potato and 2.5.5 (and 2.5.6 backported) on debian 3.0. It even happens with to 2.5.6 versions combined and linked directly without any proxy in between. rsync runs as rsync daemon on the client machines and are pulled by the central backup system. When I used it through a webproxy, the webproxy timeouted on those situations and aborted the transfer (actually aborted the CONNECT session). So I changed over to a directly routed solution, but now the command just sits there and waits. Hint's would be highly appreciated, as currently our backups are everything else than reliable :-( bye, Georg -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: -b --suffix '' --delete --backup-dir /path/ combination doesnot act as expected
On Fri, Aug 01, 2003 at 01:51:53AM -0700, jw schultz wrote: If for some reason they specify --suffix=~ --backup-dir=../foo it should create the backup files with the requested suffix. Yes, I totally agree. Fortunately, that's what the code does. We want to send the suffix if they specified one even if they specified the default. No, there's no need to do that. What you're missing is that the default is when they specified --backup-dir, so the code only sends the suffix if it is not a null string in that case. If they specified --suffix=~, it gets sent when --backup-dir was specified. (We don't send '~' only when --backup-dir was _not_ specified.) ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: -b --suffix '' --delete --backup-dir /path/ combination doesnot act as expected
On Fri, Aug 01, 2003 at 09:57:15AM -0700, Wayne Davison wrote: On Fri, Aug 01, 2003 at 01:51:53AM -0700, jw schultz wrote: If for some reason they specify --suffix=~ --backup-dir=../foo it should create the backup files with the requested suffix. Yes, I totally agree. Fortunately, that's what the code does. We want to send the suffix if they specified one even if they specified the default. No, there's no need to do that. What you're missing is that the default is when they specified --backup-dir, so the code only sends the suffix if it is not a null string in that case. If they specified --suffix=~, it gets sent when --backup-dir was specified. (We don't send '~' only when --backup-dir was _not_ specified.) Doh! Sorry, i'll go bang my head agaist the wall now. -- 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.catb.org/~esr/faqs/smart-questions.html
Re: [rsync@b] Re: rsync 2.5.6 globbing bug
I must say I'm slightly dismayed by the less-than-enthusiastic response I have received - I've identified a problem, root-cause it and even offered to submit a fix - what exactly is the problem? While I don't know about the ins-and-outs of globbing libraries (and, therefore, can't judge ease, etc)... The whole it's rare [and an obscure (imo) work around exists] so let's not worry about it is a reason to reject a feature, NOT a bug fix. As Alan already has done much and is prepared to do more of the work, I hope his patch is accepted. A voice of one (or half?), Bert -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: [rsync@b] Re: rsync 2.5.6 globbing bug
On Fri, Aug 01, 2003 at 07:18:40PM -0400, Bert wrote: I must say I'm slightly dismayed by the less-than-enthusiastic response I have received - I've identified a problem, root-cause it and even offered to submit a fix - what exactly is the problem? While I don't know about the ins-and-outs of globbing libraries (and, therefore, can't judge ease, etc)... The whole it's rare [and an obscure (imo) work around exists] so let's not worry about it is a reason to reject a feature, NOT a bug fix. As Alan already has done much and is prepared to do more of the work, I hope his patch is accepted. A voice of one (or half?), Bert The only bug is that it doesn't report that you have exceeded the capacity of the command-line argument globbing. Extending the capacity of command-line argument globbing would be an enhancement. There will always be a limit. -- 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.catb.org/~esr/faqs/smart-questions.html
Re: rsync 2.5.6 timeout bug
Alan Burlison wrote: That is what really happens. The client specified timeout is passed over the wire for use by the server but if the server has a value specified in rsyncd.conf that value will override the client. OK, right - thanks for the clarification. Still leaves me with the puzzle of why my rsyncs are timing out though... More investigation is obviously needed. I've been watching the traffic between the client server with ethereal, and I notice that a lot of the rsync packets are tagged as [short frame], although they do have a data payload consisting of a list of filenames interspersed with binary data (lengths/checksums I guess). The penultimate pachet sent by the server has a [short frame] tag, and the last packet sent by the server looks like it contains the names of a couple of files from the top-level directory I am syncing, followed by my string user group ids, followed by 8 nulls. The next packet back from the client is a ACK, followed by FIN, ACK - so it looks like the client is barfing on this last packet, as it prints the error in rsync protocol stream message. A few questions: Does anyone know what the [short frame] indicator means in ethereal - is it a glitch in their rsync packet decoder? If it was a real problem I'd expect rsync to fail far sooner that it actually does. Is there any documentation on the rsync protocol? Anyone have any clues as to why this failure might be happening, or how I might narrow it down? I was wondering if the packets were being fragmented between the client/server, and if that could be causing problems. I'm going to look through the client end of the rsync code over the weekend, but any tips or shortcuts would be gratefully received! -- Alan Burlison -- -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: [rsync@b] Re: rsync 2.5.6 globbing bug
jw schultz wrote: While I don't know about the ins-and-outs of globbing libraries (and, therefore, can't judge ease, etc)... The whole it's rare [and an obscure (imo) work around exists] so let's not worry about it is a reason to reject a feature, NOT a bug fix. As Alan already has done much and is prepared to do more of the work, I hope his patch is accepted. The only bug is that it doesn't report that you have exceeded the capacity of the command-line argument globbing. Extending the capacity of command-line argument globbing would be an enhancement. There will always be a limit. If rsync refused to transfer more than 1000 files per invocation would that be considered to be a bug? Of course there will always be a limit (probably how much memory you can allocate), but the current restriction seems both arbitrary and surprising, especially in this case when the underlying glob implemetation works just fine with 1000 files. -- Alan Burlison -- -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync 2.5.6 timeout bug
On Sat, Aug 02, 2003 at 01:00:47AM +0100, Alan Burlison wrote: Alan Burlison wrote: That is what really happens. The client specified timeout is passed over the wire for use by the server but if the server has a value specified in rsyncd.conf that value will override the client. OK, right - thanks for the clarification. Still leaves me with the puzzle of why my rsyncs are timing out though... More investigation is obviously needed. I've been watching the traffic between the client server with ethereal, and I notice that a lot of the rsync packets are tagged as [short frame], although they do have a data payload consisting of a list of filenames interspersed with binary data (lengths/checksums I guess). The penultimate The stuff from stat(2). No checksums yet unless you specified -c. pachet sent by the server has a [short frame] tag, and the last packet sent by the server looks like it contains the names of a couple of files from the top-level directory I am syncing, followed by my string user group ids, followed by 8 nulls. 4 bytes NULL to terminate the gid list. 4 bytes status. Everything normal so far. The next packet back from the client is a ACK, followed by FIN, ACK - so it looks like the client is barfing on this last packet, as it prints the error in rsync protocol stream message. What should have been sent next (aside from ACK) should have been a 4 byte integer of a fairly low value followed by some binary data representing the checksums or 12 bytes of NULL for a new file. Is there any documentation on the rsync protocol? I don't think so. Only the code. If i recall the comments of someone else correctly pysync is wire-compatible with rsync and might be easier to grasp. Anyone have any clues as to why this failure might be happening, or how I might narrow it down? I was wondering if the packets were being fragmented between the client/server, and if that could be causing problems. Is there any chance there is a firewall enforcing a timeout; possibly a personal firewall on the client machine? If it were the client code timing out i think there would be an error message. What you describe looks like the connection is being closed from the client end, not a timeout in the client code. -- 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.catb.org/~esr/faqs/smart-questions.html
rsync on Windows 2000?
What is the status of rsync on Windows 2000? I was looking to install it on my test system, and the download directory has a readme file that says I need the cygnus gnu-win32 library. The link refers me to the index page for cygnus, with no way to get to a download area. A google search shows many mirrors of the download directory. All I have checked are completely blank. I will confess that I have only been lightly browsing the mailing list traffic, so I may have missed something. -John [EMAIL PROTECTED] Personal Opinion Only -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync on Windows 2000?
John E. Malmberg writes: What is the status of rsync on Windows 2000? I was looking to install it on my test system, and the download directory has a readme file that says I need the cygnus gnu-win32 library. The link refers me to the index page for cygnus, with no way to get to a download area. A google search shows many mirrors of the download directory. All I have checked are completely blank. I will confess that I have only been lightly browsing the mailing list traffic, so I may have missed something. There is a pre-packaged rsync-2.5.6 (with a couple of patches), together with a minimal set of cygwin libraries at http://backuppc.sourceforge.net It also includes cygrunsrv that allows you to run rsyncd as a service. Follow the Code link and download the cygwin-rsyncd zip file. Craig -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
CVS update: rsync
Date: Fri Aug 1 07:58:41 2003 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv10438 Modified Files: backup.c Log Message: Use the new backup_suffix_len and backup_dir_len variables. Got rid of the suffix_specified kludge. Revisions: backup.c1.12 = 1.13 http://www.samba.org/cgi-bin/cvsweb/rsync/backup.c.diff?r1=1.12r2=1.13 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Fri Aug 1 07:58:45 2003 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv10451 Modified Files: options.c Log Message: Got rid of suffix_specified and instead set backup_suffix to the correct default value for the current backup_dir mode. Added two new values: backup_suffix_len and backup_dir_len. Improved some error-message code to not output duplicate errors. Revisions: options.c 1.109 = 1.110 http://www.samba.org/cgi-bin/cvsweb/rsync/options.c.diff?r1=1.109r2=1.110 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Fri Aug 1 08:01:15 2003 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv10975 Modified Files: NEWS Log Message: Mention the --backup fix. Revisions: NEWS1.116 = 1.117 http://www.samba.org/cgi-bin/cvsweb/rsync/NEWS.diff?r1=1.116r2=1.117 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Fri Aug 1 19:40:31 2003 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv23999 Modified Files: options.c Log Message: Complain if the --suffix value contains slashes (which is all too easy to accidentally have happen if you try to specify ~ with --backup-dir). Revisions: options.c 1.110 = 1.111 http://www.samba.org/cgi-bin/cvsweb/rsync/options.c.diff?r1=1.110r2=1.111 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Fri Aug 1 20:19:51 2003 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv27999 Modified Files: options.c Log Message: Change the way we pass the --suffix option to the remote process so that a string that starts with ~ doesn't get modified. Revisions: options.c 1.111 = 1.112 http://www.samba.org/cgi-bin/cvsweb/rsync/options.c.diff?r1=1.111r2=1.112 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
