Re: Overly Long File Names
On Wed, Oct 03, 2007 at 10:30:55AM +0100, Stuart Halliday wrote: Cygwin needs to drop support for Windows 98. They plan to do this 'sometime'. I wonder if defining MAXPATHLEN to a larger value would work or not? That value is supposed to represent the largest string that can be passed to a file-handling OS function. If it is smaller than what calls such as open() can handle successfully, increasing it will tell rsync what the real limit is. The value I've seen under cygwin is a pitiful 512 bytes or so, which is much smaller than the normal 4096 of other systems. ..wayne.. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: reducing file list bytes transferred
Thanks for that. Doesn't the delta-transfer algorithm compare the files on sender and receiver? For the file list, we would only need compare the new file list with the last one on the sender (it would be a simple matter to check that the receiver's file list is still valid with a checksum). If the same rsync command is done over and over on a huge number of files, then a command like --save_list=path/filename could be used specify where to store the list (on both ends). The delta-transfer algorithm (or some difference code specific to the file lists) could be used on the sender to find differences between the new list and the saved list. After reading the chain you referenced, I realized that the rsync command should be identical (no change in options) for this to work without side-effects, since I infer that the file list generated depends on the options. One possibility is to store the rsync command used to generate the list along with the saved list, to check that the list is still valid. I'm sure there are many rsync users out there who would benefit from this. Still rsync is greatly appreciated. Peter On 10/1/07, Peter Salameh [EMAIL PROTECTED] wrote: Has the rsync team considered an rsync option which would remember the last file list on both ends, and only send changes to the list? Perhaps a more natural approach is to use the delta-transfer algorithm to send the file list. Jamie Lokier suggested this approach here: http://lists.samba.org/archive/rsync/2007-August/018345.html Matt -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: reducing file list bytes transferred
I agree that rsync being stateless is a good thing. I have found it very reliable and predictable for years. I certainly wouldn't change to unison (which apparently is currently not maintained) just to speed up the file list transfer. Delta-transfer of the file list seems to make good sense for rsync, especially for one-way backup involving lots of files. Is there any chance that this will happen, or any way to gauge interest in this? Peter Unison ( http://www.cis.upenn.edu/~bcpierce/unison/ ) is a stateful two-way synchronizer that does essentially this by default; you can use Unison even for your one-way copy to get the performance benefit. Rsync is meant to be stateless, so if it were enhanced to reduce the amount of file list transferred, I think delta-transferring the file list would be more in keeping with its mission than saving a last file list. Matt -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Any ide why it take long time to run from WinXP to Linux?
I am using rsync2.5.1 on winxp, to rsync about 6GB working directory to linux host via ssh. rsync /cygdrive/c/work -arvvze ssh.exe --delete \ odc4linux1.am.necel.com:/home2/duong/PC_Backup This should be an weekly update run, and it took over 2-hrs . work/weekly/2007/ work/weekly/2007/Thiep Status Report Apr-30-2007.doc work/weekly/2007/Thiep Status Report July-20-2007.doc work/weekly/2007/Thiep Status Report Mar-03-2007.doc work/weekly/Weekly Report Template.doc total: matches=420050 tag_hits=420767 false_alarms=111 data=555359304 wrote 530242949 bytes read 2551080 bytes 56701.33 bytes/sec total size is 7732580895 speedup is 14.51 PC system is connecting to 100Mb port, and linux system is connecting to 1000Mb (Cisco Switch) Anyone know why it take this long? Thanks. Thiep -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Rsync not able to transfer over jumbo frames?
Hello, I have 2 network cards on my 2 of my computers that I am trying to transfer data on. The second network cards are specifically for transferring files between the two so I enabled jumble frames by setting the mtu to 9000. I seem to be able to connect between the two via ssh and other methods using this setting so I thought everything was working right until I tried rsync. I used the following command and got the error below: # rsync -auv -e 'ssh' [EMAIL PROTECTED]:/srv/data /srv/data Password: receiving file list ... Read from remote host 192.168.30.20: Connection reset by peer rsync: connection unexpectedly closed (8 bytes received so far) [receiver] rsync error: unexplained error (code 255) at io.c(459) [receiver=2.6.8] I'm using rsync 2.6.8 on both ends and never had this problem before until I changed the mtu. Anyone know of a way to fix this or does rsync not work with jumbo frames? Thanks, - Jake -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
CVS update: rsync/patches
Date: Thu Oct 4 01:09:34 2007 Author: wayned Update of /data/cvs/rsync/patches In directory dp.samba.org:/tmp/cvs-serv15713/patches Modified Files: ignore-case.diff Log Message: Added a manpage entry and made a few more tweaks. Revisions: ignore-case.diff1.59 = 1.60 http://www.samba.org/cgi-bin/cvsweb/rsync/patches/ignore-case.diff?r1=1.59r2=1.60 ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
