Re: Trouble with password (daemon mode) Thanks, trouble solved.
Hello Dennis, Tuesday, October 21, 2003, 1:32:25 AM, you wrote: DC> I running rsync in daemon mode (rsync --daemon) DC> Everything seems to work well until I try to protect item with DC> password. Thanks, the problem was in rights on file rsyncd.secrets - it was world readable while option strict was set to true by default. -- Best regards, Dennismailto:[EMAIL PROTECTED] -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Trouble with password (daemon mode)
Hello. I running rsync in daemon mode (rsync --daemon) Everything seems to work well until I try to protect item with password. here is my /etc/rsyncd.conf : use chroot = yes max connections = 10 syslog facility = local5 [ftp] path = /var/ftp comment = ftp secrets file = /etc/rsyncd.secrets auth users = gate1 here is my /etc/rsyncd.secrets gate1:abcdefg Here is the result of execution : /etc > rsync rsync://[EMAIL PROTECTED]/ftp/ Password: @ERROR: auth failed on module ftp rsync: connection unexpectedly closed (87 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(165) /etc > What could it be ??? I have RSync 2.5.6 running on FreeBSD 4.8 -- Best regards, Dennis mailto:[EMAIL PROTECTED] -- 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: files deleted on server end during transfer
As a follow up to my question...I tried syncing a directory with some files of zero length and it appears that they are causing the problems. The message says "Windows - Delayed Write Failed" "Windows was unable to save all the data for the file \Device\HarddiskVolume1\Test\(filename of 0 lenght file) The data has been lost. The error may be caused by a failure of your computer hardware or network connection. Please try to save this file elsewhere." Any ideas why I would get this? I have been doing some searching at groups.google.com and have found that other people aren't having any trouble mirroring files with leghth of zero. --Luke > Does rsync handle cases where files have been deleted off of the rsync > server side after the client starts downloading from the server? I did a > test run using two windows machines and the client puked, giving me some > kind of file protection error. What happened is the client received it's > list, starts downloading, all is well. Well, on the server side the > files were moved out (or deleted) by another process that runs on that > box. When rsync got to downloading from the directory those files were > stored in I got approximately 50 dialog boxes in windows (one for each > file) with some kind of file protection error (sorry, don't remember the > exact message). There are also some empty files on the server side that > need to be there...could these be the culprit? Are there any command > line switches to suppress these error messages? Any help would be > appreciated! > > --Luke Matthews > > > -- > To unsubscribe or change options: > http://lists.samba.org/mailman/listinfo/rsync Before posting, read: > http://www.catb.org/~esr/faqs/smart-questions.html -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
files deleted on server end during transfer
Does rsync handle cases where files have been deleted off of the rsync server side after the client starts downloading from the server? I did a test run using two windows machines and the client puked, giving me some kind of file protection error. What happened is the client received it's list, starts downloading, all is well. Well, on the server side the files were moved out (or deleted) by another process that runs on that box. When rsync got to downloading from the directory those files were stored in I got approximately 50 dialog boxes in windows (one for each file) with some kind of file protection error (sorry, don't remember the exact message). There are also some empty files on the server side that need to be there...could these be the culprit? Are there any command line switches to suppress these error messages? Any help would be appreciated! --Luke Matthews -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
symlinks
I'm trying to sync a tree containing symbolic links to files outside that directory tree. I've tried with -L and --copy-unsafe-links but apparently the files pointed by symbolic links are always re-copied over and over again regardeless whether they have been modified or not. I can hardly believe this is feature, but if this is the case, what combination of options would let me copy files pointed by symlinks *only* if changed on the local directory? Cheers, -- walter pelissero http://www.pelissero.de -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
v2.5.6 on AIX and large files
Abstract: Looking for technical assistance with rsync version 2.5.6 protocol 26 on AIX. Trying to use rsync (version 2.5.6) to sync two AIX-based systems the other day, and a couple of the filesystems (7 out of 18 in total) gave the following error message: rsync: writefd_unbuffered failed to write 32768 bytes: phase "unknown": Broken pipe rsync error: error in rsync protocol data stream (code 12) at io.c(515) Typical command used was: rsync --archive --whole-file --one-file-system /sapdb/SP1/data6 sap06:/sapdb/SP2 2>> $logfile and the network interface being used was Gigabit Ethernet, the disk in both cases being hosted on an SAN system. So there's plenty of disk and LAN capacity. I've Googled for this problem, and the only references I can find for it, seem to imply either LAN/IP-stack problems or problems with the source data. I've got a problem believing either of these since: a. I managed to send the failing file systems quite successfully using standard "rcp" (remote copy) command. In fact rcp was twice as fast as rsync (23MB/s+ v's 10-11MB/s) which I'm worried about. b. No other problems noted with intersystem comms or these filesystems. c. Other file systems which worked fine with rsync contained more data - and were therefore larger - than some of the failing ones, so it's not a file system size issue. At the time I tried playing with some of the rsync parameters, dropping --whole-file and adding --partial, with no success. Oh, and I'm not using an rsync server/daemon nor ssh. I've now done some more digging and all the filesystems that failed to sync contain one or more files that are larger than 2GB in size. So it looks to me like the latest version, on AIX at least, isn't large file enabled/aware. If anyone's got any flashes of inspiration on either the large file "problem", or the lack of performance, I'd be really interested/grateful Regards Bob Cross. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This message is confidential. It may also be privileged or protected by other legal rules. It does not constitute an offer or acceptance of an offer, nor shall it form any part of a legally binding contract. If you have received this communication in error, please let us know by reply then destroy it. You should not use, print, copy the message or disclose its contents to anyone. E-mail is subject to possible data corruption, is not secure, and its content does not necessarily represent the opinion of this Company. No representation or warranty is made as to the accuracy or completeness of the information and no liability can be accepted for any loss arising from its use. This e-mail and any attachments are not guaranteed to be free from so-called computer viruses and it is recommended that you check for such viruses before down-loading it to your computer equipment. This Company has no control over other websites to which there may be hypertext links and no liability can be accepted in relation to those sites. Scottish Courage Limited Registered in Scotland, Registered Number 65527 Registered Office: 33, Ellersly Road, Edinburgh, EH12 6HX Head Office: 160 Dundee Street, Edinburgh, EH11 1DQ * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * -- 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: --bwlimit not working right
On Fri, Oct 17, 2003 at 10:23:27AM -0500, John Van Essen wrote: > On 17 Oct 2003, Rene Schumann <[EMAIL PROTECTED]> wrote: > > > Hello! > > > > I cant get the bwlimit option working right. > > If i set this option over 400 kbyte per sec i still only get 400kbyte > > per sec, whether wich value i set. > > I try this option with a 100MB big file. > > I use a debian stable System with rsync version 2.5.6cvs protocol > > version 26. > > Can someone tell me how i can this get working? > [ snip ] > > We use --bwlimit extensively and have experienced the same 400 kB limit. > So you are doing nothing wrong. It's just the nature of the beast in > the way that it is implemented. > > Linux systems have a granularity of 10 ms. Wait times cannot be > shorter than that, and are rounded up if necessary. Only _Some_ Linux systems have a 10ms granularity inversely known as HZ or jiffies of 100HZ. This does not apply to all Linux systems, merely the most common. If memory serves Alphas run at 1024HZ and PPC at 1000HZ. I don't recall the default rate for ARM or sparc. With the 2.6 kernel the default ia32 clock rate was raised to 1000HZ (approximate) and may be arbitrarily set. > If you are pulling data (vs. pushing data) then rsync uses a buffer > size of 4096. > > The forumla used to calculate the sleep time in microsecs is: > > bytes_written * 1000 / bwlimit > > 4096 * 1000 / 400 = approx. 10,000 > > So attempts to use bwlimit greater than 400 ends up with a wait > time that is rounded up to 10,000, which is effectively 409.6 kB/s > given the 4096 byte buffeer size. Thus the apparent ceiling. > > There is a proposed patch to accumulate wait times to make it > more accurate which would probably solve your problem. See this > thread in the archives: > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg07270.html You are certainly welcome to try one of the patches. Or create your own patch that uses nanosleep which i think more appropriate than select. You may also wish to move bandwidth management to outside of rsync if you need more than 4Mb/s but less than what rsync can deliver. -- 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: --bwlimit not working right
Hello! Thanxs for you explicitely explanation. Am Fre, 2003-10-17 um 17.23 schrieb John Van Essen: > On 17 Oct 2003, Rene Schumann <[EMAIL PROTECTED]> wrote: > > > Hello! > > > > I cant get the bwlimit option working right. > > If i set this option over 400 kbyte per sec i still only get 400kbyte > > per sec, whether wich value i set. > > I try this option with a 100MB big file. > > I use a debian stable System with rsync version 2.5.6cvs protocol > > version 26. > > Can someone tell me how i can this get working? > [ snip ] > > We use --bwlimit extensively and have experienced the same 400 kB limit. > So you are doing nothing wrong. It's just the nature of the beast in > the way that it is implemented. > > Linux systems have a granularity of 10 ms. Wait times cannot be > shorter than that, and are rounded up if necessary. > > If you are pulling data (vs. pushing data) then rsync uses a buffer > size of 4096. > > The forumla used to calculate the sleep time in microsecs is: > > bytes_written * 1000 / bwlimit > > 4096 * 1000 / 400 = approx. 10,000 > > So attempts to use bwlimit greater than 400 ends up with a wait > time that is rounded up to 10,000, which is effectively 409.6 kB/s > given the 4096 byte buffeer size. Thus the apparent ceiling. > > There is a proposed patch to accumulate wait times to make it > more accurate which would probably solve your problem. See this > thread in the archives: > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg07270.html > > A corrected patch is in the next message (7271). -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
