Re: working on a 2.5.6pre1 release
On Thu, Jan 09, 2003 at 05:09:07PM -0600, Dave Dykstra wrote: > I'm stuck on a problem that some machines on build.samba.org are > showing on the 'chgrp' test. I've checked in a fix for this bug. Here's what I discovered: The reason only the chgrp test failed is that it is the only test that uses -vvv instead of just -vv. This is significant because -vvv is needed for the receiver to try to do IO after killing off the generator. This IO would sometimes fail if the generator died before it finished. More specific details: (Background) The receiver forks off the generator with an error pipe open from the generator to the receiver. The receiver notes this error-receiving fd so that it gets monitored on all IO (and thus remains unblocked). (The bug) When the receiver signals the generator to die, it was not clearing io_error_fd, and thus if it did any IO that just happened to occur after the generator closed its end of the pipe, the IO would notice the EOF on io_error_fd and cause the receiver to exit with error 12. Now that rsync properly notices the return value of the receiver process, this causes the sender to also exit with an error. (The fix) Just call io_set_error_fd(-1) prior to signaling the generator to die. I've appended the patch I just checked in. ..wayne.. ---8<--8<--8<--8<---cut here--->8-->8-->8-->8--- Index: main.c --- main.c 9 Jan 2003 19:04:06 - 1.157 +++ main.c 10 Jan 2003 08:28:39 - @@ -461,6 +461,7 @@ } io_flush(); + io_set_error_fd(-1); kill(pid, SIGUSR2); wait_process(pid, &status); return status; ---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: working on a 2.5.6pre1 release
On Fri, Jan 10, 2003 at 12:46:13AM -0800, Wayne Davison wrote: > This is significant because -vvv is needed for the receiver to try to > do IO after killing off the generator. This IO would sometimes fail > if the generator died before [the IO] finished. For the anal, I mixed up the generator and the receiver in my entire description of the problem. It is the generator that kills (and forks off) the receiver, not the other way around. Fortunately this slip of terminology in my email does not adversely affect the patch at all. ..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: IPv6 hosts allow|deny
On Thu, 9 Jan 2003, Dave Dykstra wrote: > I went ahead and submitted Hideaki's patch pretty much as is. I took off > the ifdef around the memset at the beginning of client_sockaddr() because > I figured it wouldn't hurt to do anywhere. Besides, it was checking > for a specific operating system (__linux__) which we like to avoid and > because there was a typo in the check for HAVE_SOCKADDR_IN6_SCOPE_ID > (it was HAVE_SOCKADDR_IN6_SOCPE_ID). I noticed that there was code in > access.c that was accessing the same sockaddr_in6 sin6_scope_id field that > was protected by ifdef in clientname.c so I put the same ifdef around > the code in access.c. I also updated the rsyncd.conf.yo documentation > to allow for IP address of the IPv6 form. > > I have not tested this, I hope it works. Dave, Sorry for the late reply, been busy. I'm going to test with the committed patch, and will let you know. I can only test on linux, however. Bert Vermeulen [EMAIL PROTECTED] -- Profanity is the inevitable linguistic crutch of the inarticulate motherfucker. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Help With Restoring
I'm very interested in this... My question(s) are why did you have to install a minimal system? Could you have just booted up with network and rsync and just rsynced to a freshly paritioned/formatted disk? What command did you use (to clarify) to make the origal rsync's of your disk, and what were the steps neccessary and the command you used (to clarify) to make the restore? (I guess that includes the install of a base system.. did you use the same system, say redhat 7.2?) I'm curious because i have a full rsync of a production server on my development box, and i put it in Lilo to boot up with, disconnected the network (so know conflicts occur, would any?) and tried to boot, but it failed... (i don't have access right now to the error message). The production box is i686 and so is the development box... Not the same processor though would that make a difference? Do you think if i just tried to install a minimal system to a partion and copied the / tree it would work?? Thanks a bundle! Great job on the success!! And Good luck for the future! -Chris On Thursday 09 January 2003 01:58 pm, [EMAIL PROTECTED] wrote: > To Mike and the Rsync community, > > This is by far the greatest utility I have ever used for backing > up an entire system. My Redhat server got botched during an upgrade. I > reformatted my partitions and installed a minimal system. Rsync'ed the > entire / directory back and the server came back to life. databases, > websites, hardware configs, everything! I'm back in business. As a Linux > newbie, not a luser, I really appreciate the response I received from Mike > and others. As the days pass and my skills refine, I will offer back as > much support as I can. I guess you can say another BillyBorg saved :) > > > Thanks Again! > > Mark > > > > > rsync --delete --stats --compress --recursive --times --perms > > --links > > > > > --rsh=/usr/bin/ssh --exclude "tmp/" --exclude "dev/" --exclude > > "proc/" > > > > > --exclude "backups/ " --delete-excluded --backup > > > > --backup-dir=/backup2/BACKED_UP_SERVER_FQDN/$DAY -a /* > > > > CENTRAL_SERVER_IP:/backup2/BACKED_UP_SERVER_FQDN/current && echo > > "Daily > > > > > backup ran on `date`" >> /var/log/backup.log > > > > > > Notice that if you have any dotfiles in / (that is, flies that begin > > with > > > > a "."), this will not copy them, but normally you wouldn't have > > dotfiles > > > > in / so it shouldn't matter. Might want to start using / instead of > > /* > > > > from now on though, just for good form. > > > > Thanks fot the tip :) > > > > > > This has been working fine and I've even been able to restore files > > using > > > > > scp from time to time. now I'm faced with a bare metal recovery > > > > cause of a > > > > > > botched upgrade from Redhat 7.1 to 8.0 that failed half way through. > > This > > > > > machine was still accessible via console and ssh (putty). I signed > > in via > > > > > ssh and ran... > > > > > > > > # cd / > > > > # scp -r CENTRAL_SERVER_IP:/backup1/BACKED_UP_SERVER_FQDN/current/.* > > . > > > > > This was running for a while and then i lost my connection and cant > > > > reconnect. I won't have console access till the morning but any > > advice > > > > > would be greatly appreciated. > > > > > > Don't you mean: > > > > > > scp -rp CENTRAL_SERVER_IP:/backup1/BACKED_UP_SERVER_FQDN/current/. . > > > > > > ? > > > > > > The command you list above won't copy anything, since there are no > > > dotfiles in the root directory. Also, you have backup2 in the rsync > > > command and backup1 in the scp command. > > > > > > Maybe that was just a typo though... > > > > As never having restored anything more that a few files at a time as > > the Linux newbie that I am, I'm sure i was off. Thanks for the tip > > again :) > > > Typo it was. Should have been backup2 in the scp command. > > > > > One final thought. Sometimes scp has issues with symlinks (as in, > > copying > > > > the target instead of the link). Might want to use: > > > > > > cd / > > > rsync -av CENTRAL_SERVER_IP:/backup1/BACKED_UP_SERVER_FQDN/current/ . > > > > I will try this first thing in the morning when I have console access. > > > > Just one more thing; Based on the script I use, am I SOL or with a > > little elbow greese in the morning get my server back? > > > > Thank you for your time and advice. I really appreciate it! > > > > Mark > > > > > Mike > > > > > > -- > > > To unsubscribe or change options: http://lists.samba. > > > org/mailman/listinfo/rsync > > > Before posting, read: > > http://www.tuxedo.org/~esr/faqs/smart-questions.html Content-Type: text/html; charset="us-ascii"; name="Attachment: 1" Content-Transfer-Encoding: 7bit Content-Description: -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Problem with french characters
Hi, I have a problem synchronizing a windows directory to a linux directory. The filenames on the windows machine have sometimes french characters with accents (quite usual for french language...). Rsync or the filesystem of the linux box can obviously not handle this character type and create filenames with unreadable symbols in it. After the first sync the files/folders with such characters can not be opened or edited. I use the newest rsync version on both systems, on windows the one which comes with the cygwin shell (2.5.5.2), on linux the one which comes with RedHat 8.0 (ver. 2.5.5). I also use ssh (openssh 3.4p1) for encryption but I don't think this is the cause. Anybody ever seen this kind of failure ? I there a chance to give rsync the correct codepage so it can transfer the files with correct names ? Thanks for your help Oliver Krehan -- 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: working on a 2.5.6pre1 release
On Fri, Jan 10, 2003 at 12:46:13AM -0800, Wayne Davison wrote: > On Thu, Jan 09, 2003 at 05:09:07PM -0600, Dave Dykstra wrote: > > I'm stuck on a problem that some machines on build.samba.org are > > showing on the 'chgrp' test. > > I've checked in a fix for this bug. Thanks, Wayne! Great work. I think the remaining build on build.samba.org are not enough to delay putting out pre1, but it would be good if those of you who care about the following ports would try to come up with some fixes before we do the final release: 1. The CRAY SV1 UNICOS machine is not compiling, complaining that it can't take the address of the bit field in sin.sin_addr.s_addr. I think the solution may be to assign that value to a local variable and then copy it into the structure element, but it isn't clear to me what the type of the local variable should be. 2. The Linux ia64 and Alpha and the OpenBSD Sparc64 ports are all failing the daemon-gzip-upload and daemon-gzip-download tests even though the basic daemon test succeeds. The OpenBSD test reports a core dump, and I suspect they're all having the same problem related to 64 bit. 3. The Stratus VOS port is failing all 3 daemon tests in code that is used just for testing, saying it can't create the test socket. I don't know if there's a corresponding problem in the corresponding non-test code. 4. The NetBSD i386 port is failing the chgrp test. I think if I can find the time today I want to work a little yet on the --copy-unsafe-links problem and on the unsafe-* tests and then I'll make the pre1 version. - 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: make clean
I checked in this patch. - Dave On Thu, Jan 09, 2003 at 06:41:19PM -0800, jw schultz wrote: > I just did a make clean to tidy up a bit and found four > objects were missed. The seem to belong to the CHECK_PROGS > set. Not sure where best to put them so created a > CHECK_OBJS variable and added it to the clean rule. > > > -- > > J.W. SchultzPegasystems Technologies > email address: [EMAIL PROTECTED] > > Remember Cernan and Schmitt > Index: Makefile.in > === > RCS file: /cvsroot/rsync/Makefile.in,v > retrieving revision 1.84 > diff -u -r1.84 Makefile.in > --- Makefile.in 8 Apr 2002 06:23:34 - 1.84 > +++ Makefile.in 10 Jan 2003 02:40:34 - > @@ -43,6 +43,9 @@ > # Programs we must have to run the test cases > CHECK_PROGS = rsync tls getgroups trimslash t_unsafe > > +# Objects for CHECK_PROGS to clean > +CHECK_OBJS=getgroups.o t_stub.o t_unsafe.o trimslash.o > + > # note that the -I. is needed to handle config.h when using VPATH > .c.o: > @OBJ_SAVE@ > @@ -106,7 +109,7 @@ > cat $(srcdir)/*.c $(srcdir)/lib/compat.c | awk -f $(srcdir)/mkproto.awk > >$(srcdir)/proto.h > > clean: cleantests > - rm -f *~ $(OBJS) rsync $(TLS_OBJ) $(CHECK_PROGS) > + rm -f *~ $(OBJS) rsync $(TLS_OBJ) $(CHECK_PROGS) $(CHECK_OBJS) > > cleantests: > rm -rf ./testtmp* -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Windows and default --modify-window=0
Ok, I agree --modify-window should default to 2 (or 1 if that's all that's really needed) on cygwin. However, I don't like os-specific defines. That _WIN32 we've got there is the only one currently in the code, and there's no occurrances of __CYGWIN__. I'd rather have a configure.in rule for it. Any suggestions on a good one? At a minimum there's an AC_CYGWIN macro but that's not much different than just checking for __CYGWIN__. Probably it would be worth calling AC_CYGWIN and then setting a DEFAULT_MODIFY_WINDOW to 2 in configure if $CYGWIN=yes. As far as I know there is no other port of rsync to Windows yet except under Cygwin so I don't think it is worth putting in extra code to support something that may never be used. Or, perhaps we should key off of the $EXEEXT variable which gets set to '.exe' on Windows; anybody have an opinion on that? - Dave On Thu, Jan 09, 2003 at 02:41:21PM -0800, jw schultz wrote: > On Thu, Jan 09, 2003 at 11:21:36PM +0100, Lapo Luchini wrote: > > jw schultz wrote: > > > > >The 2 second timestamp resolution only applies to some > > >windows filesystems. I think NTFS has timestamp resolution > > >in the milliseconds (unlrelated to precision). It should > > >only become an issue when the windows filesystem is the > > >destination. > > > > > This message says it is 2 seconds aso on NTFSD actually: > > http://lists.samba.org/pipermail/rsync/2000-July/002491.html > > I don't use windows myself. I just recall that one of the > windows filesystem has timestamps in the milliseconds. > > > >Further examination shows that it is > > >already hacked in options.c for win32: > > >| #ifdef _WIN32 > > >| int modify_window=2; > > >| #else > > >| int modify_window=0; > > >| #endif > > >perhaps something just needs to be added to the #ifdef. > > > > > Ohhh... I'd add CygWin to the #ifdef too, then. > > Grr, I *never* remember what does cygwin define and what not ^_^ > > > > Let me check... this message > > http://sources.redhat.com/ml/gdb-patches/2001-04/msg00039.html > > suggests that to include djgpp, mingw and cygwin the full ifdef should be: > > > > #if defined(__GO32__) || defined(_WIN32) || defined (__CYGWIN__) > > > > Should I add that to the current 2.5.5 cygwin port (creating a -3 release) > > or 2.5.6 will be short in time? > > Depends on how urgent this is. Given you have a workaround > i'd get it in cvs and wait. Assuming the 2.5.6 really does > happen soon. > > Please try a modify-window of 1. Maybe my math is off > somehow but i don't think it needs to be greater than 1. > Take a look at the code in util.c. If you truncate to 2 > second resolution and compare against 1 second resolution > the difference should never be greater than 1 second. > It won't make a difference very often but i'd still feel > better making the window as small as possible. > > -- > > 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 -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: IPv6 hosts allow|deny
In article <[EMAIL PROTECTED]> (at Wed, 8 Jan 2003 08:24:13 -0600), Dave Dykstra <[EMAIL PROTECTED]> says: > In particular, I see that yours includes documentation changes and his > doesn't. Sorry,... One reason why I did not include manpage is that I'm not so good at English... Here's the description of the extension: - Syntax is the same - We can write IPv6 address in hosts allow / hosts deny - Host, prefix and netmask are supported. You can write: - 3ffe::dead:beef::1 - 3ffe::dead:beef::/64 - 3ffe::dead:beef::/::::: or even - ::0123:4567:89ab:cdef/::::: Note that scope-id is also supported: - fe80::1%eth0 - fe80::%eth0/64 - fe80::%eth0/::::: -- Hideaki YOSHIFUJI @ USAGI Project <[EMAIL PROTECTED]> GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA -- 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: working on a 2.5.6pre1 release
Dave Dykstra [mailto:[EMAIL PROTECTED]] wrote: > 3. The Stratus VOS port is failing all 3 daemon tests in code >that is used just for testing, saying it can't create the test >socket. I don't know if there's a corresponding problem in the >corresponding non-test code. The socketpair_tcp calls fail because we do not implement non-blocking connects. This is a known bug in VOS (stcp-1178) for which no fix is currently available. And there is no way to work around this in the socket.c code. I have updated the comment that appears in the output log to explain this. Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies. Day: +1 978-461-7557; FAX: +1 978-461-3610 Speaking from Stratus not for Stratus -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Long-pending patch for Stratus VOS build
The following patch still applies cleanly to the current cvs copy of rsync. I apply it each night after I grab rsync from the build farm. Without it, I don't get far at all. The purpose of the patch is to add executable extension handling, which we need, and to clean up a few POSIX things and supply defaults for a few #defines we don't have. (See the original letter for full details). Does anyone object to having these changes applied now, during the pre-release phase? http://lists.samba.org/pipermail/rsync/2002-November/008937.html Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies. Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Windows and default --modify-window=0
Dave Dykstra wrote: > Ok, I agree --modify-window should default to 2 (or 1 if that's all > that's really needed) on cygwin. However, I don't like os-specific > defines. They have the advantage that the entire logic is visible in the .c file, rather than split between the .c and configure.in. > That _WIN32 we've got there is the only one currently in the code, and > there's no occurrances of __CYGWIN__. I'd rather have a configure.in > rule for it. Any suggestions on a good one? At a minimum there's an > AC_CYGWIN macro but that's not much different than just checking for > __CYGWIN__. Probably it would be worth calling AC_CYGWIN and then > setting > a DEFAULT_MODIFY_WINDOW to 2 in configure if $CYGWIN=yes. AC_CYGWIN is obsolete - the autoconf manual recommends something like this: AC_CANONICAL_HOST # at some point above case $host_os in *cygwin* ) DEFAULT_MODIFY_WINDOW=2;; * ) DEFAULT_MODIFY_WINDOW=0;; esac AC_SUBST(DEFAULT_MODIFY_WINDOW) > As far as I > know there is no other port of rsync to Windows yet except under > Cygwin > so I don't think it is worth putting in extra code to support > something > that may never be used. Or, perhaps we should key off of the $EXEEXT > variable which gets set to '.exe' on Windows; anybody have an opinion > on > that? Yuk! :-) Max. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Long-pending patch for Stratus VOS build
On Fri, Jan 10, 2003 at 01:23:45PM -0500, Green, Paul wrote: > The following patch still applies cleanly to the current cvs copy of rsync. Or did before the most recent Makefile.in changes. It's easy to merge this one problem, though. > Does anyone object to having these changes applied now, during the > pre-release phase? Here are my comments on the changes: + The Makefile.in changes look very safe and needed. + The install-sh change to the dsttmp value looks good. ? I have a question about the portability of the u_FOO -> uFOO_t changes. The former is the BSD syntax for the unsigned FOO typedefs, and the latter is what, POSIX? The changes work on Linux, at least. Perhaps we should just make these changes and try it out on the compile farm. + The inet_pton changes look right to make the code consistent. The only possible glitch might be a system that has a prototype for inet_pton() but not the library code -- if the prototype conflicts, the compile would fail (there are ways to work around this, but let's worry about that if we actually find some weird system with this problem). I'd be glad to check in the "+" changes now if Dave thinks now is a good time. ..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: Help With Restoring
"Dr. Poo" <[EMAIL PROTECTED]> wrote on 01/11/2003 09:25:18 AM: > I'm very interested in this... > > My question(s) are why did you have to install a minimal system? > Could you have just booted up with network and rsync and just rsynced to a > freshly paritioned/formatted disk? And your probably right but I wasn't comfortably clear on how and my time to at least get the web server up was short. I did try to boot off the floppy I made back when I first installed the system but that didn't work. So I decided to get myself into a working environment with all the pieces needed like a shell, networking, rsync, and anything else a minimal install will do to make things work. > > What command did you use (to clarify) to make the original rsync's of your > disk, and what were the steps neccessary and the command you used (to > clarify) to make the restore? (I guess that includes the install of a base > system.. did you use the same system, say redhat 7.2?) Well I'm sure these steps might look silly to the experienced but it worked and saved a years worth of my investment in learning, research and development on this box :) This started trying to upgrade to Redhat 8.0 with the Kernel on the CD 2.4.18-14 Client Server... Linux version 2.4.18-3smp ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.3 2.96-110)) #1 SMP Thu Apr 18 07:27:31 EDT 2002 MemTotal: 126116 kB processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 11 model name : Intel(R) Pentium(R) III CPU family 1133MHz stepping : 1 cpu MHz : 1130.497 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 2254.43 Here is the script I used to back up to a central server: #!/bin/sh PATH=/usr/local/bin:/usr/bin:/bin DAY=`date +%A` export PATH DAY [ -d /root/emptydir ] || mkdir /root/emptydir rsync --rsh=/usr/bin/ssh --delete -a /root/emptydir/ CENTRAL_SERVER_IP:/backup2/BACKED_UP_SERVER_FQDN/$DAY rmdir /root/emptydir rsync --delete --stats --compress --recursive --times --perms --links --rsh=/usr/bin/ssh --exclude "tmp/" --exclude "dev/" --exclude "proc/" --exclude "backups/ " --delete-excluded --backup --backup-dir=/backup2/BACKED_UP_SERVER_FQDN/$DAY -a /* CENTRAL_SERVER_IP:/backup2/BACKED_UP_SERVER_FQDN/current && echo "Daily backup ran on `date`" >> /var/log/backup.log Here is the schedule: 0 2 * * * /etc/cron.customs/backups Here is the central backup server: Linux version 2.4.7-10 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-98)) #1 Thu Sep 6 17:27:27 EDT 2001 MemTotal: 255344 kB processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 0 model name : Intel(R) Pentium(R) 4 CPU 1400MHz stepping : 10 cpu MHz : 1395.777 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss tm bogomips : 2785.28 OK. So now I lost my client server... 1) Booted the server off of the Redhat 8.0 Disk 1 of 3 2) Custom Install 3) Manually Partition with Disk Druid All the partition information was already there. The path was missing but when I went into edit each partition, all i had to do was click the drop down arrow twice to populate the path field with the original. I choose to format each partition. (I was also able to confirm my partition table by looking at my last backup stored on the central server /etc/fstab. Nice to have if a new disk was required :) 4) Choose Minimal System on the Package Selection page 5) Added myself to the system Let er rip After the install and reboot 6) signed on as me and got to a command line $ su # cd / # rsync -avv --rsh=/usr/bin/ssh CENTRAL_SERVER_IP:/backup1/BACKED_UP_SERVER_FQDN/current/ . Because I was root, it asked for the root password on the server. I watched as it tailed through all the files being rsync'd. When it was done... # /sbin/shutdown -r now And it came back up as if nothing has happened, so I hope :-/ So far so good though :) > > I'm curious because i have a full rsync of a production server on my > development box, and i put it in Lilo to boot up with, disconnected the > network (so know conflicts occur, would any?) and tried to boot, but it > failed... (i don't have access right now to the error message). > > The production box is i686 and so is the development box... Not the same > processor though would that make a difference? I doubt that your processor mismatch can be an issue. >
Re: Long-pending patch for Stratus VOS build
On Fri, Jan 10, 2003 at 11:33:00AM -0800, Wayne Davison wrote: > On Fri, Jan 10, 2003 at 01:23:45PM -0500, Green, Paul wrote: > > The following patch still applies cleanly to the current cvs copy of rsync. > > Or did before the most recent Makefile.in changes. It's easy to merge > this one problem, though. > > > Does anyone object to having these changes applied now, during the > > pre-release phase? > > Here are my comments on the changes: > > + The Makefile.in changes look very safe and needed. > > + The install-sh change to the dsttmp value looks good. > > ? I have a question about the portability of the u_FOO -> uFOO_t >changes. The former is the BSD syntax for the unsigned FOO typedefs, >and the latter is what, POSIX? The changes work on Linux, at least. >Perhaps we should just make these changes and try it out on the >compile farm. > > + The inet_pton changes look right to make the code consistent. The >only possible glitch might be a system that has a prototype for >inet_pton() but not the library code -- if the prototype conflicts, >the compile would fail (there are ways to work around this, but let's >worry about that if we actually find some weird system with this >problem). > > I'd be glad to check in the "+" changes now if Dave thinks now is a good > time. Ok, go ahead. I think it's ok to try out the ? patch on the compile farm too. I know that Cygwin also uses $(EXEEXT), but apparently its make has been more thoroughly modified to handle things automatically so the Makefile doesn't have to use it as much. I'm looking at the --copy-unsafe-links problem and it looks very badly broken. I was the one who put it in the first place based on a contributed patch, and now I'm not sure it ever worked. It's going to take a while to trace through the history to figure out if it worked once and if so when it broke. The fix is not likely to impact much, though, so I don't think 2.5.6pre1 will need to be held up because of it because it can go in later. - 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
Rsync --daemon v 2.5.5 v26 causing kernel panic
Has anyone seen this? Looking for past experiences / ideas. Will post progress. I'm tracking down a problem that seems to be caused by rsync. When moving files from a remote server I get a kernel panic. We have a number of servers that back up to a main box -- the panic only occurs when a specific client backs up. It occurs on the box it is backing up to -- not the client. The kernel is Linux 2.4.20 (just compiled -- no patches), files are stored on a 4 disk raid (80GB Western Digital drives, software raid) with Reiserfs. This is being done over a vpn connection controlled by another machine (gateway machine) running tinc so we're not using ssh or any other shell on the rsync machine. I have: recompiled rsync at both locations recompiled the kernel from new source code (panic in 2.4.19, system rebooted in 2.4.20) I will: try different hardware run a file system check at the main system (the one that crashes) exclude directories in the backup (rsync one directory at a time -- see where it crashes) I did notice filenames on the client machine that contain control characters -- but they seem to have backed up before. -- 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: Help With Restoring - system disk exercise experience
Here's my experience with a recent full restore exercise on a system/boot disk which is among the more interesting scenarios. Rsync Backup Overview - I've a script based on Mike Rubel's rsync/snapshot backup notes (www.mikerubel.org) with two primary differences: 1. Files that no longer exist on the client are not deleted on the backup server. This trades true incremental backup function for a slightly more storage space. 2. Each incremental backup is touched & tagged with it's original root time stamp. This provides iterations limited only by the backup server's capacity. I worked for Network Appliance when remote mirroring was relatively new, and was particularly delighted to replicate the functionality so easily thanks to Mike and so many others. Anyway, for each client the backup server pull cycle is basically: cd snapshot if (client) cp -al client client.old rsync -a -e ssh --stats $client.excludes client:/ client touch timestamp(s) and over time: # find snapshot -maxdepth 1 -ls 2448014 drwxr-xr-x 29 root root 4096 Jan 3 12:48 snapshot/dell 4416354 drwxr-xr-x 29 root root 4096 Dec 28 21:30 snapshot/dell.2002.12.28-21:30 1420716 4 drwxr-xr-x 29 root root 4096 Dec 23 14:24 snapshot/dell.2002.12.23-14:24 # ls -F snapshot/dell A/ backup/ bootblock.446 etc/ lib/ opt@sbin/ vid/ C/ big/ cdr/ floppy/ lost+found/ root/ tmp@ welcome.msg E/ bin/ cdrom/ home/mnt/ rsync.exclude usr/ welcome.msg~ Z/ boot/dev/ kits/net/ rsync.exclude~ var/ zip/ Excludes are /proc, /tmp, /var/tmp, /var/spool, .netscape/cache + client particulars. Full Drive Restore Exercise --- The restore test assumed total drive failure. The process was more tedious than I had previously thought through: 1. Power cycle the server to attach a new drive. 2. Manually replicate the partition structure on the new drive. You would need to have previously saved each logical drive's map or have a really good memory i.e.- fdisk -l /dev/sda | sed 's/^/#/' >> /etc/fstab 3. Individually create file system or swap init on each partition. 4. Individually mount and copy each data partition with special attention to / for directories that are mount points i.e.- mount /dev/sdd4 /mnt; cd /snapshot/dell/usr; cp -a . /mnt; umount /mnt 5. Restore the boot sector if applicable. 6. Power cycle the server to remove the newly rebuilt drive. If server power cycles were undesirable, I could have worked on the client (drive swap, minimal boot, restore the network, network copies). Tedious or not the good news is the backup clone booted and functioned perfectly. If anyone can improve on the restore steps, I'd like to hear back. The scripting development time does not seem worth it unless there were enough clients to skew complete system disk failure probabilities. I'm glad I did the exercise as there is now a defined albeit labor intensive process for worst case. Rgds, tim. "Dr. Poo" wrote: > > I'm very interested in this... > > My question(s) are why did you have to install a minimal system? > Could you have just booted up with network and rsync and just rsynced to a > freshly paritioned/formatted disk? > > What command did you use (to clarify) to make the origal rsync's of your > disk, and what were the steps neccessary and the command you used (to > clarify) to make the restore? (I guess that includes the install of a base > system.. did you use the same system, say redhat 7.2?) > > I'm curious because i have a full rsync of a production server on my > development box, and i put it in Lilo to boot up with, disconnected the > network (so know conflicts occur, would any?) and tried to boot, but it > failed... (i don't have access right now to the error message). > > The production box is i686 and so is the development box... Not the same > processor though would that make a difference? > > Do you think if i just tried to install a minimal system to a partion and > copied the / tree it would work?? -- -- 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 --daemon v 2.5.5 v26 causing kernel panic
On Fri, Jan 10, 2003 at 02:25:57PM -0600, Edward King wrote: > Has anyone seen this? Looking for past experiences / ideas. Will post > progress. > > I'm tracking down a problem that seems to be caused by rsync. When > moving files from a remote server I get a kernel panic. > > We have a number of servers that back up to a main box -- the panic only > occurs when a specific client backs up. It occurs on the box it is > backing up to -- not the client. > > The kernel is Linux 2.4.20 (just compiled -- no patches), files are > stored on a 4 disk raid (80GB Western Digital drives, software raid) > with Reiserfs. This is being done over a vpn connection controlled by > another machine (gateway machine) running tinc so we're not using ssh or > any other shell on the rsync machine. > > I have: > > recompiled rsync at both locations > recompiled the kernel from new source code (panic in 2.4.19, system > rebooted in 2.4.20) > > I will: > > try different hardware > run a file system check at the main system (the one that crashes) > exclude directories in the backup (rsync one directory at a time -- see > where it crashes) > > I did notice filenames on the client machine that contain control > characters -- but they seem to have backed up before. Just to confirm: You are doing backup-server initiated pull something like "rsync server::module destdir" and the machine you execute this on (the receiver) panics. Rsync will of course not be the culprit. However, rsync is very good at stressing a system and the kernel developers have found it to be a common test case. Most likely it is a hardware fault. Probably timing sensitive. I'd check the logs for oopses and and disk errors. Also try downgrading the mode with hdparm. If this isn't a obvious hardware fault you should report it to the linux-kernel people. Look on www.kernelnewbies.org for instructions. This will be of interest to the developers of md, reiserfs and the specific IDE driver. -- J.W. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
RE: Long-pending patch for Stratus VOS build
Wayne Davison [mailto:[EMAIL PROTECTED]] wrote: >Here are my comments on the changes: > ? I have a question about the portability of the u_FOO -> uFOO_t > changes. The former is the BSD syntax for the unsigned FOO typedefs, > and the latter is what, POSIX? The changes work on Linux, at least. > Perhaps we should just make these changes and try it out on the > compile farm. Yes, uFOO_t is POSIX, 1990, IIRC. Thanks! PG -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
ÎÒºÜÇî×ã²ÊÔ¤²â×ÊÁÏ2003ÄêµÚÒ»ÆÚ£¡£¡£¡
ÎÒºÜÇî2003ÄêµÚÒ»ÆÚ×ã²ÊÔ¤²â×ÊÁÏ 1¡¢²©ÂåÄáÑÇVSACÃ×À¼ »ðÌì´óÓУº´ÓØÔÃû¿´£¬Ö÷¶Ó»ñʤµÄ¿ÉÄÜÐԽϴ󣬵«¸¸Ä¸³ÖÊÀ£¬µ£ÐÄÖ÷¶ÓÄÜȡʤ£¬Ó¦»ðÉúÊÀÍÁ£¬¶ÔÖ÷¶ÓÓÐÀû¡£2س±äµÃµ½ÀëΪ»ð£¬±ÈºÍØÔË«·½ÄÑ·Öʤ¸º£¬¹Ù¹í³ÖÊÀ¶ÔÖ÷¶Ó²»Àû£¬Ó¦Ë®¿ËÊÀ»ð¶Ô¿Í¶ÓÓÐÀû£¬µ«ÈÕ½¨ÊÜÊÀ»ðËùº¦£¬¶ÔÖ÷¶ÓÓÐÀû¡£ÈÕ½¨ÖúӦˮ£¬¶Ô¿Í¶ÓÓÐÀû¡£ÍƼö£º01£¨3£© 2¡¢²¼À×Î÷ÑÇVSÀÆë°Â µØÀ׸´£ºÄ¾¿ËÍÁ¶Ô¿Í¶ÓÓÐÀû£¬Ó¦ÍÁ¿ËÊÀË®¶Ô¿Í¶ÓÓÐÀû£¬2س±äµÃµØÔóÁÙ£ºÍÁÉú½ð£¬¶Ô¿Í¶ÓÓÐÀû£¬ÈÕ½¨¿ËÊÀľ£¬»¯È¥¹Ù¹íµÄΣº¦£¬µ«Ê±½¨ÖúÊÀľ£¬²¢²»ÄÜÍêÈ«»¯È¥¹Ù¹íµÄΣº¦¡£Í¬Ê±£¬Ó¦Ë®ÉúÊÀľ£¬¶ÔÖ÷¶ÓÓÐÀû¡£ÍƼö£º1£¨0£© 3¡¢¿ÆĪVSÑÇÌØÀ¼´ó Ë®À×ÍÍ£ºË®Éúľ¶Ô¿Í¶ÓÓÐÀû£¬µ«ÊÀľ¿ËÓ¦ÍÁ¶ÔÖ÷¶ÓÓÐÀû¡£6س±äµÃ·çÀ×Ò棺±ÈºÍ·â£¬Ë«·½ÄÑ·Öʤ¸º£¬µ«Ó¦Ä¾¿ËÊÀÍÁ£¬¶Ô¿Í¶ÓÓÐÀû£¬Í¬Ê±ÈÕ½¨¿ËӦľ£¬¶Ô¿Í¶Ó²»Àû£¬µ«Ó¦Ä¾¿ËÊÀÍÁ£¬¶Ô¿Í¶ÓÓÐÀû¡£ÍƼö£º31£¨0µÄ¿ÉÄÜÐÔ½ÏС£© 4¡¢¹ú¼ÊÃ×À¼VSĦµÂÄÉ »ðµØ½ú£º»ðÉúÍÁ¶Ô¿Í¶ÓÓÐÀû£¬ÐֵܳÖÊÀ£¬Ö÷¶ÓºÄʧ¡£3س±äµÃ»ðɽÂ㺴ÓØÔÃû¿´£¬Ö÷¶ÓÓÌÈçÔÚÂÃ;£¬Æ®¸¡²»¶¨£¬¸¸Ä¸³ÖÊÀ¶øÉúÓ¦½ð£¬¶Ô¿Í¶ÓÓÐÀû£¬µ«ÈÕ½¨ÖúÊÀÍÁ¶øÍú£¬¶ÔÖ÷¶ÓÓÐÀû¡£ÍƼö£º3£¨1µÄ¿ÉÄÜÐÔ½ÏС£© 5¡¢ÓÈÎÄͼ˹VSÀ×¼ªÄÉ Ôó·ç´ó¹ý£º½ð¿Ëľ¶ÔÖ÷¶ÓÓÐÀû£¬µ«´ÓØÔÃû¿´£¬Ö÷¶ÓÄÑÒÔȡʤ¡£3س±äµÃÔóË®À§£º½ðÉúË®£¬¶Ô¿Í¶ÓÓÐÀû£¬´ÓØÔÃû¿´£¬Ö÷¶ÓȡʤÀ§ÄÑ¡£µ«Ó¦Ë®ÉúÊÀľ£¬¶ÔÖ÷¶ÓÓÐÀû£¬Ê±½¨ÉúÊÀľ£¬¶ÔÖ÷¶ÓÓÐÀû¡£ÍƼö£º1£¨3£© 6¡¢Æ¤ÑÇÇÙ²ìVSÅÁ¶ûÂê µØ·çÉý£ºÄ¾¿ËÍÁ£¬¶Ô¿Í¶ÓÓÐÀû£¬Æ޲ƳÖÊÀ£¬¶ÔÖ÷¶ÓÓÐÀû¡£5س±äµÃË®·ç¾®£ºË®Éúľ¶Ô¿Í¶ÓÓÐÀû£¬²Æ³ÖÊÀ£¬¶ø¿ËӦˮ£¬¶ÔÖ÷¶ÓÓÐÀû£¬µ«ÈÕ½¨Ê±½¨ÖúӦˮ¶øÍú£¬¶Ô¿Í¶ÓÓÐÀû¡£ÍƼö£º03 7¡¢ÂÞÂíVSÇÐÎÖ ·çÀ×Ò棺±ÈºÍØÔ£¬µ«²Æ³ÖÊÀ£¬¶ÔÖ÷¶ÓÓÐÀû£¬5س±äµÃɽÀ×ÒãºÄ¾¿ËÍÁ£¬¶Ô¿Í¶ÓÓÐÀû£¬µ«²Æ³ÖÊÀ¶ÔÖ÷¶ÓÓÐÀû£¬ÊÀÍÁ¿ËӦˮ£¬¶ÔÖ÷¶ÓÓÐÀû¡£µ«ÈÕ½¨ÖúӦˮ¶øÍú£¬Ë«·½ÊƾùÁ¦µÐ¡£ÍƼö£º13 8¡¢ÎÚµÏÄÚ˹VSÅå³¼Ö Ë®À×ÍÍ£ºË®Éúľ£¬¶Ô¿Í¶ÓÓÐÀû£¬ÊÀľ¿ËÓ¦ÍÁ£¬¶ÔÖ÷¶ÓÓÐÀû¡£2س±äµÃË®Ôó½Ú£º½ðÉúË®£¬¶ÔÖ÷¶ÓÓÐÀû£¬ÊÀ»ð¿ËÓ¦½ð£¬¶ÔÖ÷¶ÓÓÐÀû£¬µ«ÈÕ½¨ÖúÓ¦½ð¶øÍú¡£Í¬Ê±Ê±½¨º¦ÊÀ»ð£¬¶ÔÖ÷¶Ó²»Àû¡£ÍƼö£º13 9¡¢ÀÊ˹VSÉ«µ± Ë®»ð¼È¼Ã£ºË®¿Ë»ð¶ÔÖ÷¶ÓÓÐÀû£¬µ«ÐÖ³ÖÊÀ£¬¶ÔÖ÷¶Ó²»Àû£¬Ö÷¶Ó·Àʧ¡£5س±äµÃµØ»ðÃ÷ÒÄ£º´ÓØÔÃû¿´£¬Ö÷¶ÓȡʤÀ§ÄÑ¡£¹Ù¹í³ÖÊÀ£¬¶ÔÖ÷¶Ó²»Àû£¬µ«ÈÕ½¨º¦Ó¦Ä¾£¬¶ÔÖ÷¶ÓÓÐÀû¡£Ó¦Ä¾¿ËÊÀÍÁ£¬¶Ô¿Í¶ÓÓÐÀû¡£Ê±½¨ÖúӦľ¶øÍú¡£ÍƼö£º13£¨0¿ÉÄÜÐÔ½ÏС£© 10¡¢ÀÕ°¢¸¥¶ûVS˹ÌØÀ˹±¤ »ðɽÂ㺻ðÉúÍÁ£¬¶Ô¿Í¶ÓÓÐÀû£¬×ÓËï³ÖÊÀ£¬¿É±£Æ½°²£¬2س±äµÃ»ð·ç¶¦£º±íÊ¢´óµÄÇìºØ£¬¹Ù¹í³ÖÊÀ£¬¶ÔÖ÷¶Ó²»Àû£¬Ó¦ÍÁ¿ËÊÀË®£¬¶Ô¿Í¶ÓÓÐÀû£¬µ«ÈÕ½¨ÖúÊÀË®¶øÍú£¬µ«Ô½¨ÖúÓ¦ÍÁ¶øÍú¡£ÍƼö£º31£¨0¿ÉÄÜÐÔ½ÏС£© 11¡¢Ä¦ÄɸçVS°Í˹µÙÑÇ »ðɽÂ㺻ðÉúÍÁ£¬¶Ô¿Í¶ÓÓÐÀû£¬×ÓËï³ÖÊÀ£¬¿É±£Æ½°²£¬2س±äµÃ»ð·ç¶¦£º±íÊ¢´óµÄÇìºØ£¬¹Ù¹í³ÖÊÀ£¬¶ÔÖ÷¶Ó²»Àû£¬Ó¦ÍÁ¿ËÊÀË®£¬¶Ô¿Í¶ÓÓÐÀû£¬µ«ÈÕ½¨ÖúÊÀË®¶øÍú£¬µ«Ô½¨ÖúÓ¦ÍÁ¶øÍú¡£ÍƼö£º31£¨0¿ÉÄÜÐÔ½ÏС£© 12¡¢Äá˹VSÀï¶û Ìì·ç¥:½ð¿Ëľ£¬¶ÔÖ÷¶ÓÓÐÀû¡£2س±äµÃÌìɽ¶Ý£ºÍÁÉú½ð£¬¶ÔÖ÷¶ÓÓÐÀû¡£ÊÀ»ð¿ËÓ¦½ð£¬¶ÔÖ÷¶ÓÓÐÀû£¬µ«¹Ù¹í³ÖÊÀ¶ÔÖ÷¶Ó²»Àû¡£×ÓËï·¢¶¯¶ø˳¿Ë£¬¶ÔÖ÷¶ÓÓÐÀû¡£ÍƼö£º3£¨1£© 13¡¢²¨¶û¶àVSÃɱËÀû°£ ·çÌìСÐ󣺽ð¿Ëľ£¬¶Ô¿Í¶ÓÓÐÀû£¬Ó¦ÍÁ¿ËÊÀË®£¬¶Ô¿Í¶ÓÓÐÀû¡£4س±äµÃǬΪÌ죺±ÈºÍØÔ£¬Ë«·½ÄÑ·Öʤ¸º£¬µ«²Æ³ÖÊÀ£¬¶ÔÖ÷¶ÓÓÐÀû¡£ÍƼö£º3£¨1£© ±¾ÆÚÇ¿¶Ó¶àÊýÔÚÖ÷³¡£¬±¨ÀäµÄ¿ÉÄÜÐÔ²»ÊǺܴ󣬵«ÄѶÈÈ´²»Ð¡¡£ÒÔÉϸ´Ê½Ì«¶à£¬ÏÖËõΪÒÔϸ´Ê½£º03£¬10£¬310£¬3£¬3£¨1£©£¬03£¬1£¨3£©£¬13£¬310£¬30£¬31£¬3£¨1£©£¬3£¨1£©¡£´ó¼Ò¿É¸ù¾ÝÉÏÃæ×ÊÁϵĸÅÊö£¬´ÓÖÐÑ¡ÔñÊôÓÚ×Ô¼ºµÄÄÇÒ»×¢500Íò¡£±¾ÆÚ±¾ÈË×¼±¸Í¶£º0£¬1£¬31£¬3£¬31£¬03£¬31£¬31£¬13£¬30£¬13£¬13£¬3Öеļ¸×¢µ½50×¢²»µÈ¡£±¾ÈËûÓÐÔËÆø£¬Ï£Íû´ó¼Ò×Ô¼º´Ó×ÊÁÏÖÐÕÒ³öÊôÓÚÄãµÄÄÄÒ»×¢£¬²»Ò»¶¨¸ú×ÅÎÒͶ¡£±ÈÈçµÚÒ»³¡£¬ÓÐÐí¶àÈËÈÏΪÊÇ1£¬Æäʵ03µÄ¿ÉÄÜÐÔ×î´ó¡£µÚ¶þ³¡£¬ÀÆë°ÂÁ¬Ðø¶à³¡²»°Ü£¬Ò²ÐíÓÐÈËÈÏΪËü¸ÃÖÕ½áÁË¡£µ«±¾ÈËÈÏΪ1µÄ¿ÉÄÜÐÔ×î´ó¡£ÂÞÂíºÜÈÝÒ×±»ÇÐÎÖ±Æƽ¡£ÀÊ˹ºÍÉ«µ±£¬´ò³Éʲô½á¹û¶¼²»Îª¹ý¡£Äá˹VSÀï¶û1µÄ¿ÉÄܴܺó¡£Ô¤²âÊý¾ÝÖ»×÷²Î¿¼,Ͷע¾ö²ß»¹µÃ¿¿Äã×Ô¼º¶¨¶á¡£À¨ºÅÄÚµÄΪ³öÏֵĻú»á½ÏС£¬Ò»°ãС¶îͶע¿É²»Ó迼ÂÇ¡£±¾×ÊÁÏÿÆÚ50Ôª¡£ÈçÐ趩ÔÄÇëÁªÏµQQ£º18419276 Email:[EMAIL PROTECTED]) ĵµ¤¿¨ºÅ£º4580 6865 8224 7749 ¿ª»§ÐУº¹¤ÉÌÒøÐÐÖØÇìÊзÖÐÐÓªÒµ²¿ ÐÕÃû£ºÐìÔ¾¸£¡£ ÀÏ¿Í»§¿É7ÕÛÓÅ»Ý5ÆÚÒÔÉÏ£¬10ÆÚÒÔÉÏ65ÕÛ£¬ÓàϵÄÈ«¶©¿É6ÕÛÓŻݡ£Òѵ½ÆÚµÄÓû§£¬±¾ÆÚΪ×îºóÒ»ÆÚÊÔÓá£×îºó×£´ó¼ÒÐÂÄêµÚÒ»ÆÚÖÐ´ó½± -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
