Re: [PATCH] rsync kills all user processes on fork failure
On May 9, 4:51pm, [EMAIL PROTECTED] (Dave Dykstra) wrote:
-- Subject: Re: [PATCH] rsync kills all user processes on fork failure
>
> What's the best fix against the current CVS? Should we back out the
> previous fix because that one only solved half the problem? Somebody
> please provide an updated patch.
>
-- End of excerpt from Dave Dykstra
I've appended an updated patch that can be applied to the current CVS.
Description:
-- Be extra careful: reject any negative pid in do_fork(),
not just -1 (since other negative values would also be
harmful if they were ever passed to kill, even though
such values should never occur).
-- Expand all_pids[] dynamically as needed in do_fork(), to
avoid any possibility of overflow.
-- Prevent kill(-1, SIGUSR2) in main.c; this is independent of
the interaction between do_fork() and kill_all(), which
involves SIGUSR1.
Bob Byrnese-mail: [EMAIL PROTECTED]
Curl Corporation phone: 617-761-1200
400 Technology Square, 8th Floor fax:617-761-1201
Cambridge, MA 02139
--- util.c.orig Thu May 9 22:12:37 2002
+++ util.c Thu May 9 22:15:20 2002
@@ -373,15 +373,25 @@
}
-static pid_t all_pids[10];
+static pid_t *all_pids;
static int num_pids;
+static int max_pids;
+
+#define MIN_PIDS 16
/** Fork and record the pid of the child. **/
pid_t do_fork(void)
{
pid_t newpid = fork();
- if (newpid != 0 && newpid != -1) {
+ /* we must ensure that newpid == -1 is not recorded in all_pids
+ if fork() fails, otherwise kill_all() could nuke the world! */
+ if (newpid > 0) {
+ if (num_pids >= max_pids) {
+ max_pids = (max_pids ? 2*max_pids : MIN_PIDS);
+ all_pids = (pid_t *)Realloc(all_pids, sizeof(pid_t)*max_pids);
+ if (!all_pids) out_of_memory("do_fork");
+ }
all_pids[num_pids++] = newpid;
}
return newpid;
--- main.c.orig Thu May 9 22:12:31 2002
+++ main.c Thu May 9 22:15:28 2002
@@ -408,6 +408,13 @@
;
}
+ /* if fork fails, we must avoid doing kill(-1, SIGUSR2) later,
+ since that could nuke the world! */
+ if (pid < 0) {
+ rprintf(FERROR,"could not fork in do_recv: %s\n",strerror(errno));
+ exit_cleanup(RERR_IPC);
+ }
+
close(recv_pipe[1]);
close(error_pipe[1]);
if (f_in != f_out) close(f_in);
--
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: wildcards (was Re: a problem I'm having with rsync-4.5.4)
On Thu, 9 May 2002, Dave Dykstra wrote: > How many times would you have to call fnmatch for every file? We'd call fnmatch() an extra time for every slash in the path. However, the performance hit of this new loop on the pattern "foo/*" would be the same as using the two patterns "/**/foo/*" & "/foo/*" (_except_ that the trailing '*' would work right in the first pattern) -- this is because "**" already has to do a recursive match iteration, and that's kind of what our new loop would be doing outside of fnmatch() (we'd actually be doing less recursive calls, since fnmatch() would call itself an extra time for every character in the path, but our loop would only call for every character after a slash). So yes, this is slightly less efficient for unanchored patterns. It would make the code work as advertised, though, and any pattern that was anchored with a leading slash would be entirely unaffected. On the downside, it could cause some people who use unanchored patterns as if they were actually anchored to be surprised by the change in behavior. ..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
Re: Status Query - Please respond - Re: Patch to avoid 'Connection reset by peer' error for rsync on cygwin
On Thu, May 09, 2002 at 04:22:45PM -0700, Martin Pool wrote: > shutdown(fd, 1); Perhaps use SHUT_WR instead of 1? -- 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: Status Query - Please respond - Re: Patch to avoid 'Connection reset by peer' error for rsync on cygwin
On 9 May 2002, Dave Dykstra <[EMAIL PROTECTED]> wrote: > The answer has to come from Martin and I haven't seen anything posted > from him lately, he must be unavailable. Sorry, I've been out of town this week. > On Tue, May 07, 2002 at 03:28:06PM +0100, Max Bowsher wrote: > > Hi. > > > > On the one hand, I don't want to annoy anyone with repeated emails :-), but on > > the other, I would like to know the chances of the patch making it in to 2.5.6. > > > > Even if the answer is 'Maybe - too busy to think about it right now', I will be > > satisfied, but if I need to revise it before it can be considered, I would like > > to know that. This is the shutdown one, right? I wanted to check about portability before we put it in. Snader's "Effective TCP/IP Programming" says that shutdown(fd, 1); is OK on both Unix and Windows and will avoid errors from closing the socket. So I think it's OK to put it in. Winsock misinterprets other values of the second parameter so we can't use them. I don't understand why you need to only insert this call here and not in every case where a socket is closed. If there's no specific reason we should have a common shutdownsocket() routine and call it; if there is a reason we should document it. 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] rsync kills all user processes on fork failure
On Thu, 9 May 2002, Dave Dykstra wrote: > On Wed, May 08, 2002 at 09:44:25PM -0700, Jos Backus wrote: > > On Wed, May 08, 2002 at 11:31:18PM -0400, Bob Byrnes wrote: > > > http://rsync.samba.org/cgi-bin/rsync/incoming?id=2762;user=guest;selectid=2762 > > Fwiw, the patch looks good to me. rsync doesn't seem to handle -1 == fork() > > here, leading to the problem described. > What's the best fix against the current CVS? Should we back out the > previous fix because that one only solved half the problem? Somebody > please provide an updated patch. My patch inspired version 1.109 of rsync/util.c, http://cvs.samba.org/cgi-bin/cvsweb/rsync/util.c.diff?r1=1.108&r2=1.109&f=h but there's other stuff there too, so you don't want to just undo it. I'm off to a meeting now. If no one else gets around to it, I can repackage Bob's patch sometime late tomorrow. The context has changed a bit, so the original won't apply without a few minor tweaks. In addition to the kill -1 stuff, Bob also had a few lines of code to prevent going off the end of the all_pids[] array. > - 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: wildcards (was Re: a problem I'm having with rsync-4.5.4)
On Thu, May 09, 2002 at 02:32:59PM -0700, Wayne Davison wrote: > On Thu, 9 May 2002, Dave Dykstra wrote: > > I would say it's definitely too risky for 2.5.6. > > What would you say to adding a (simple) loop to the fnmatch() code that > would cause unanchored things like "foo/*/bar" to not be bound to the > start of the filename? This would make it work in an equivalent way to > the unanchored non-wildcard strings. How many times would you have to call fnmatch for every file? Sounds like a CPU eater. - 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] rsync kills all user processes on fork failure
On Wed, May 08, 2002 at 09:44:25PM -0700, Jos Backus wrote: > On Wed, May 08, 2002 at 11:31:18PM -0400, Bob Byrnes wrote: > > http://rsync.samba.org/cgi-bin/rsync/incoming?id=2762;user=guest;selectid=2762 > > Fwiw, the patch looks good to me. rsync doesn't seem to handle -1 == fork() > here, leading to the problem described. What's the best fix against the current CVS? Should we back out the previous fix because that one only solved half the problem? Somebody please provide an updated patch. - 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: Trouble with transferrig LARGE files...
On Sun, May 05, 2002 at 12:32:19PM +0200, A.G. van der Vlies wrote: > > Hi, > I am at loss. When I try to transfer a (one, 1) large file (+32G) I > get a timeout error. A data protocol error in io.c. When track it down > a bit I find that there has been a 'dip' on the socket level > > On both ends I use 2.5.5. I have tried transferring without the -z > option. If I compress the file and then send it (+4G) I have no > problem. I have used the -P and the --bwlimit option without succes. > > Having read the archive I think there are some problems with large > file, however none of the suggested solutions aplly. > > Can this prob be solved?? I have never tried a file that large, but what do you mean by a "dip" on the socket level? Are you doing an initial copy or are you updating an existing file? What's the command line you use, and what's the operating system? - 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: wildcards (was Re: a problem I'm having with rsync-4.5.4)
On Thu, 9 May 2002, Wayne Davison wrote: > What would you say to adding a (simple) loop to the fnmatch() code that Just to clarify (since the above is poorly worded) -- I meant adding the loop to the rsync code that calls fnmatch(), not trying to modify the fnmatch() code directly. ..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
Re: wildcards (was Re: a problem I'm having with rsync-4.5.4)
On Thu, 9 May 2002, Dave Dykstra wrote: > I would say it's definitely too risky for 2.5.6. What would you say to adding a (simple) loop to the fnmatch() code that would cause unanchored things like "foo/*/bar" to not be bound to the start of the filename? This would make it work in an equivalent way to the unanchored non-wildcard strings. ..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
Re: A simpler move-files patch
On Thu, 9 May 2002, Dave Dykstra wrote: > Maybe I'm dense, but I don't see how that's any different from turning > on a flag (with the opposite meaning) at the end. The reason this makes a difference is that not all the files get into that code. Any files that are identical just get skipped over on the generator side, so the sender never sees them (in that loop). So, the sender needs to assume that we can delete all the files in the list until we're told what files are not identical. An alternate way to implement this is to modify the generator process to send a special "this file is identical" sequence when we're in file- moving mode. That would allow the sending process to remove identical files immediately on the sending side, and then we could just mark the differing files with a "delete me" flag after we finish sending out all the updates. Another thought just occurred to me on how to implement this without resorting to a post-processing pass. It might be possible to have the receiver send the "delete me" events over the error message pipe (rather than the redo pipe), and since the generator already keeps this pipe unblocked, that would allow the code to work without first fixing the redo pipe's blockability. I can check into this. ..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
Re: rsync.samba.org
On Fri, May 03, 2002 at 05:39:42PM -0400, pyxl wrote: > Howdy everybody, > > Dunno if anyone's got a log monitor or mailing script set up for 404 > errors on rsync.samba.org, but > http://rsync.samba.org/rsync/fom-serve/cache/1.html > emits a 404. It's where the the FAQ-O-Matic nav link that's found > throughout the site eventually sends the browser. > > Sorry about posting this to the listserv, couldn't find a "tell the > webmaster" link anywhere. > > Scott I don't know who else to tell to fix this but Martin, and I haven't seen anything from him lately. Meanwhile, I discovered that if you manually remove the "rsync/" from the above URL or change "rsync.samba.org" to "samba.org" you can get the pages to come up. - 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: openssh 3.1 and rsync dont work
When we first switched to openssh 3.1 with rsync 2.3.1 we had the same error from ssh-rand-helper. But after switching to rsync 2.5.5rc1 the problem went away. (this is on AIX). -- Jim Ogilvie On Thu, 9 May 2002 09:34:57, Dave Dykstra wrote: > I want to fix this in rsync too. I developed what I think is a good fix > and now I'm trying to reproduce the problem so I can test whether or not > the fix worked. The trouble is, I can't reproduce it with "-e ssh" even > though I'm sure I'm running openssh 3.1p1 on solaris where it's running the > ssh-rand-helper. truss doesn't show rsync setting SIGCHLD to SIG_IGN. I > found that there is one place in the rsync 2.5.5 code that sets SIGCHLD to > SIG_IGN, but it appears to only be in rsync --daemon mode, and it wouldn't > call ssh from there. > > What version of rsync did you have the problem in, and what was the command > line you used? > - 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.5 - Utilizing "exclude from" in rsync.conf
I'm sorry I took so long to reply. Your message got lost among others. It never occured to me before, but the answer is that those excluded patterns only apply to files sent from a daemon, not those sent to it. I'm afraid you'll have to specify the exclude patterns on the client side. I will change the rsyncd.conf man page. Really the rsync daemon mode was primarily intended to send things like an http server does, and there's quite a number of subtle ways that it does not work well when on the receiving end. I usually try to discourage people from doing it. - Dave Dykstra On Fri, Apr 26, 2002 at 05:33:46PM -0400, Paul Slinski wrote: > Dave, > > Excludes worked fine from client to server. Both systems are RedHat Linux 7.2 > (2.4.18 kernel) > > Rsync output on both systems (snipped): > rsync version 2.5.5 protocol version 26 > Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles, > IPv6, 64-bit system inums, 64-bit internal inums > > Command line is > rsync -vv -a -z /home/paul/graphica/ [EMAIL PROTECTED]::test/ > > Maybe I need to use excludes on the clients instead. > > On April 26, 2002 05:23 pm, Dave Dykstra wrote: > > No, the -vv has to be on the client side. The fact that most of your > > patterns don't have a '/' in them makes them pretty simply and it seems > > like they ought to work. Excludes specified on the server can be > > overridden by the client, however. What is the command line on the client? > > Do the files get excluded if you specify it on the client side? What > > version is of rsync is running on both sides, and what are the operating > > systems? > > > > - Dave Dykstra > > -- > Paul Slinski > System Administrator > Global IQX > http://www.globaliqx.com/ > [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
Re: Possible Bug report
That behavior is intentional. If you want to force it to create parent directories you need to have a similar directory tree on the source machine and use the --relative option, for example rsync -a --relative local/bin B:/usr - Dave On Fri, Apr 26, 2002 at 12:52:20PM +0100, Ferguson, Duncan wrote: > I have a server (A) with a directory structure I want to copy to another > server (/usr/local/bin...) > On the client (B), only /usr exists (/usr/local doesn't). > > I used: > /opt/PKGrsync/bin/rsync -a --delete --force > --rsync-path=/opt/PKGrsync/bin/rsync --exclude=save -v -v /usr/local/bin > B:/usr/local/bin > > but it failed with: > opening connection using /usr/bin/ssh B /opt/PKGrsync/bin/rsync --server > -vvlogDtpr --delete --force . /usr/local/bin > building file list ... > expand file_list to 4000 bytes, did move > excluding directory bin/save because of pattern save > done > rsync: mkdir /usr/local/bin: No such file or directory > rsync error: error in file IO (code 11) at main.c(285) > rsync: connection unexpectedly closed (8 bytes read so far) > rsync error: error in rsync protocol data stream (code 12) at io.c(150) > > Creating /usr/local on B cured the problem and it worked without further > issue. It seems the mkdir should include "-p" possibly. > > Server (A) is on Solaris 2.6 5/98 105181-25 > Client (B) is on Solaris 8 02/02 108528-13 > > Thanks > > Duncs > > Duncan Ferguson > IT Infrastructure Senior Unix Systems Engineer > > Phone: 01384 264 060 > Mobile: 07968 148 748 > > > > This private and confidential e-mail has been sent to you by Egg. > The Egg group of companies includes Egg Banking plc > (registered no. 2999842), Egg Financial Products Ltd (registered > no. 3319027) and Egg Investments Ltd (registered no. 3403963) which > carries out investment business on behalf of Egg and is regulated > by the Financial Services Authority. > Registered in England and Wales. Registered offices: 1 Waterhouse Square, > 138-142 Holborn, London EC1N 2NA. > If you are not the intended recipient of this e-mail and have > received it in error, please notify the sender by replying with > 'received in error' as the subject and then delete it from your > mailbox. > > > -- > 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 "exclude-from"
Because your source is "mail/", you need to remove the mail/ from your exclude patterns. If you used "mail" without the trailing slash then you'd need it. rsync -vv should help you debug exclude patterns. - Dave Dykstra On Sat, Apr 20, 2002 at 11:18:18AM -0400, Nikolaus Hiebaum wrote: > Hi - > > I want to use rsync in combination with a list of files it should exclude, > but somewhere I seem to have a problem. > > The problem is that the files and directories I list in the file to be > excluded are in fact synchronized on the remote server. I should add that > they are not present on the remote server and shall not, thus, excluding > them from synchronization. :) > > The "exclude file" looks like this: > ---snip--- > - mail/IN.SPAM > - mail/IN.posted-usenet > - mail/backup/ > - mail/headc.gz > - mail/incoming/ > - mail/miscellaneous > - mail/saved-messages2 > - mail/sent-mail-2001/ > - mail/sent-mail2 > - mail/techstuff > ---snap--- > > In the prompt I type > > rsync -avpPz --exclude-from "exclude-from-mailsyncing" mail/ -e ssh >REMOTE_SERVER:mail/ > > It seems that the file (i.e., exclude-from-mailsyncing") with the > exclusion list is not read. There is no error message, and -v or -vv does > not give any hint where the mistake would be. > > Do you guys have any idea? > > -- > CU, Niki > *Draft beer, not people* > > > > -- > 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: Timeout issue
On Wed, May 08, 2002 at 06:26:15PM +0200, Lataille Norbert wrote: > Hello, > > I am using rsync to synchronize directories containing big files over a slow > network (the link is based on GSM). Transfering one single file may need a > few minutes. > > I use the optional parameter "--timeout=60", means to me that an IO operation > should not last more than 1 min. However, what rsync does is that it dies > (return value=30) as soon as _one_ file transfer meeds more than 1min It is supposed to be per IO operation, but between some of the parts of rsync there might be some operations that are really taking that long. There was a rsync patch put in not too many versions back which disabled a timeout on one of the parts that tended to sit around for a long time. 60 seconds sounds pretty short though. > (everything works well if I set "--timeout=3600", which is not very secure > for a production environement). In what way is that not secure? > I have looked at the archive and tried applying a patch from Neil > Schellenberger > (http://lists.samba.org/pipermail/rsync/2000-June/002466.html), but it didn't > solve the problem. Is this bug a well-known issue ? Are there patches pending > ? Before I start investigating further, do you have suggestions ? Are you using the latest version of rsync? - 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: controlling what happens to old executables?
On Wed, May 08, 2002 at 08:49:34AM -0700, Dan Stromberg wrote:
> We're hoping to switch to updating a large software collection with
> rsync.
>
> Sometimes, we'll be using rsync to push security updates, say for setuid
> binaries with a security hole. In this case, we want rsync to get rid
> of the old executable, instead of creating a ~ file or whatever.
>
> Sometimes, we'll be using rsync to push updates to programs that people
> want to leave running a long time, like a shell. In this case, we want
> the old binary to be kept around so the user doesn't get a segfault or
> something (I know, this depends on just how rsync eliminates the old
> file).
Usually what it comes down to is whether or not you're going over NFS.
A single Unix filesystem (on most modern systems) have "last-close semantics"
which doesn't actually delete an executable until all running programs
have exitted. NFS version 3 and earlier is stateless so a server can't
tell if there's any programs running on one of the clients, and the next
time the client program has to page something in the program crashes.
> Is there any way, with stock rsync, that we can control when a replaced
> file is left around for a while, and when a replaced file is removed
> immediately?
No, sorry.
> Please note that we may have some of both in the same rsync update.
>
> TIA.
>
> PS: With our current software, all backup files are removed immediately,
> unless there's a ".backup" file in the same directory that lists the
> file's name. In that case, the old file is moved to a directory called
> "..." for a week prior to being removed. So security stuff isn't
> treated specially, and shells (for example) are listed in a .backup
> file.
My distribution software also does something similar, and we set it up to
only backup programs that tend to be run overnight when most of our updates
occur. The software is based on my open source tool Not-So-Bad
Distribution (http://www.bell-labs.com/nsbd) which transfers all changed
files in a package to a scratch directory (using rsync --compare-dest) and
before moving the new files in on top of the old files it renames those
that match a pattern ("backupSubs").
- 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: rsyncd.conf;
When you use an exclude '*' you need to explicitly include all the parent directories, or they get excluded as the algorithm recurses down through the directory. If you want to include all directories you can do --include '*/'. - Dave Dykstra On Wed, May 08, 2002 at 11:20:57AM -0400, Roberts Ross wrote: > I have some rsync defined as a server on one of my production systems and > use to to sync out various configuration files for services running on the > box (dhcpd, dns named.conf files & the like). Both ends are Compaq > Alpha/Tru64 5.1 systems running rsync 2.5.5. > > I'm having a fit trying to include certain files in specific subdirectories > under the main path; one such example is below: > > [smb] > comment = Samba Configuration Files > read only = yes > path = /usr/local/samba > uid = root > include = lib/smb.conf private/username.map private/smbpasswd > exclude = * > hosts allow = 192.252.27.0/24 > hosts deny = * > > My problem is that I don't get the files. If I enable verbose logging on the > server I see: > > May 8 10:57:51 anaca2 rsyncd[374683]: add_exclude(lib/smb.conf,include) > May 8 10:57:51 anaca2 rsyncd[374683]: > add_exclude(private/username.map,include) > May 8 10:57:51 anaca2 rsyncd[374683]: > add_exclude(private/smbpasswd,include) > May 8 10:57:51 anaca2 rsyncd[374683]: add_exclude(*,exclude) > May 8 10:57:51 anaca2 rsyncd[374683]: rsync on smb/ from > anaca4.uscable.alcatel.com (192.252.27.254) > May 8 10:57:51 anaca2 rsyncd[374683]: wrote 211 bytes read 65 bytes total > size 0 > > ... and on the client I see: > > # ls > # /usr/local/bin/rsync -vvv -ar anaca2::smb/ . > opening tcp connection to anaca2 port 873 > Compaq Tru64 UNIX V5.1 (Rev. 732); Sat Aug 18 09:46:40 EDT 2001 > > > *** > > > receiving file list ... > recv_file_name(.) > received 1 names > done > recv_file_list done > get_local_name count=1 . > generator starting pid=119773 count=1 > recv_generator(.,0) > set modtime of . to (1017089370) Mon Mar 25 15:49:30 2002 > ./ > generate_files phase=1 > recv_files(1) starting > recv_files phase=1 > generate_files phase=2 > recv_generator(.,0) > recv_files finished > wrote 66 bytes read 211 bytes 554.00 bytes/sec > total size is 0 speedup is 0.00 > _exit_cleanup(code=0, file=main.c, line=925): about to call exit(0) > # ls > # > > I've tried many variations of the include-ed names.. lib/smb.conf, > /lib/smb.conf, lib/*, lib/**, *lib/smb.conf.. etc etc etc. I tried > everything on an include line with a '- *' as the last option. Some will > create the directory names, but will still not copy the files. If I remove > the include/exclude, the entire directory contents sync as expected. What > else am I doing wrong? > > Please CC me on replies; I'm not yet on the list. The Mailman page bombs out > with a bug report. :( > > Thanks, > > -r > -- > -Ross Roberts > Unix/Network Administrator > Alcatel Optical Fiber Division > 2512 Penny Rd. > Claremont, NC 28610-8634 > (828) 459-8392 (voice) > (828) 459-8437 (fax) > [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
Re: wildcards (was Re: a problem I'm having with rsync-4.5.4)
Well the modified wildmat certainly looks simpler but I think it's going to
be awfully hard to test for all the kinds of cases rsync is likely to run
into. I don't have time to look at it very closely, but I would say it's
definitely too risky for 2.5.6. The fact that it is based on previously
tested code is encouraging though.
- Dave Dykstra
On Wed, May 08, 2002 at 10:01:12AM -0700, Wayne Davison wrote:
> On Wed, 8 May 2002, Dave Dykstra wrote:
> > And in fact I think the non-wildcard-matching code actually succeeds,
> > doesn't it?
>
> Yes, sorry for the unclear sentence.
>
> > I doubt it's worth trying to fix the fnmatch() code, because fnmatch
> > is a standard function and it would be a lot of work to maintain our
> > own modified version.
>
> The thing is, we don't really want what fnmatch() does. I hadn't
> realized until I read the old bug email you cited that rsync can treat
> "*" characters as "**" (even though we mention that fact in the man
> page). I think this in itself is a good reason to replace the fnmatch()
> call with something that can distinguish between the two idioms. The
> wildmat.c code I used to create such a solution is much simpler than the
> GNU fnmatch.c code, and the test suite I used to test it indicates that
> it is working quite well. This change also means that we could get rid
> of the fnmatch() compatibility code that is in the lib dir, and I've
> already gotten rid of the code that tested if fnmatch() was broken on
> the current machine (meaning less worries for oddball architectures).
>
> As for the anchoring discrepancy, it's a simple matter to add a loop to
> the match test to check if the pattern matches later in the string.
> (This could even be done for the current fnmatch() call). This is as
> efficient as adding "**/" to the front of the string (without affecting
> its matching of base-directory names).
>
> Appended is a patch that tweaks my wildmat patch. I've optimized the
> wildmat_tail() routine to avoid an extra (useless) match loop if the
> pattern starts with "**".
>
> ..wayne..
>
> ---8<--8<--8<--8<---cut here--->8-->8-->8-->8---
> Index: lib/wildmat.c
> --- save/lib/wildmat.cWed May 8 09:36:28 2002
> +++ ./lib/wildmat.c Wed May 8 09:20:09 2002
> @@ -103,6 +103,8 @@
> int
> wildmat_tail(const char *text, const char *p)
> {
> +if (strncmp(p, "**", 2) == 0)
> + return wildmat(text, p);
> while (1) {
> if (wildmat(text, p))
> return TRUE;
> ---8<--8<--8<--8<---cut here--->8-->8-->8-->8---
--
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: A simpler move-files patch
On Tue, May 07, 2002 at 12:13:22PM -0700, Wayne Davison wrote: > On Tue, 7 May 2002, Dave Dykstra wrote: > > I am a little bit uncomfortable with the sense of the flag > > FLAG_NO_DELETE, though, because I'm afraid there might become more > > cases in the future where it should be set and we won't remember to > > add it. > > Good point. I've got a fix that removes this possibility. (See below.) > > > How complicated would it be if you instead turned on a > > FLAG_READ_SUCCEEDED in the case(s) where there were no errors? > > Doing this changes the code back into how it was working -- namely > having it only remove sender-side files that really got info sent (since > no identical files would get this flag set). I think I favor the new > way of also removing identical files. For instance, I once ran my rsync > to send some files from one system to the next and I realized that I > forgot the --move-files option, so I re-ran the command with that option > and didn't notice until later that nothing whatsoever had happened > during the second transfer (since the files were all up-to-date, nothing > was deleted on the sender). > > So, my current code turns on FLAG_NO_DELETE at the very beginning of the > section where we start to synchronize the file, and it only gets turned > off again at the end where things all finished properly. In this way > any failure-case is guaranteed to have the no-delete flag set. Maybe I'm dense, but I don't see how that's any different from turning on a flag (with the opposite meaning) at the end. > > Also, what do you think about the name --delete-sent-files instead of > > --move-files? > > I think it accurately conveys what's happening, so I can live with it > (even though it's a bit long). > > If you'd like to see the updated version of my patch, check it out here: > > http://www.clari.net/~wayne/rsync-delete-sent-files.patch - 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
