Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <42F9777B.5080206@byu.net> Date: Tue, 09 Aug 2005 21:41:47 -0600 From: Eric Blake User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Bob Brown CC: cygwin AT cygwin DOT com Subject: Re: Rsync over SSH dies before it is able to send with lots of files References: <42FA081C DOT 25957 DOT 24F4EADF AT localhost> In-Reply-To: <42FA081C.25957.24F4EADF@localhost> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Bob Brown on 8/9/2005 7:58 PM: > > rsync --progress -rtv 192.168.0.1::mydirectory/* c:\localcopy For starters, since you are using rsync recursion, get rid of the * to give rsync just a single filename at startup, rather than making bash try to expand 45000 names all at once on the command prompt: rsync --progress -rtv 192.168.0.1::mydirectory/ c:\localcopy > But, here's where it gets interesting .... the directory that I want to rsync > has got 45,000 files in it. When rsyncing from this dir, the rsync on the > server end fails. After digging further, I discovered that bash on the server > end dies with a stackdump (see below). I can avoid this by copying less > files with a wildcard (eg. 12*, 13* etc), however this shouldn't be > necessary. There are no rsync logs generated on the server when this > happens.... Hmm, you're making bash expand a wildcard into 45000 files. This shouldn't crash bash, but I'm guessing there is some of memory corruption or malloc failure when consuming so much memory all before forking(). I'll have to see if I can try and reproduce the failure. > - Mounted the directory that I'm copying from elsewhere and made it > executable (worth a crack) The only difference you might make to get a larger command line argument length is to make rsync's directory mounted executable (not the directory you are copying). But if bash is crashing instead of creating a command line that long in the first place, there's no hope to this attempt. > > bash-3.00$ cat bash.exe.stackdump > Exception: STATUS_ACCESS_VIOLATION at eip=610022AE > eax=61259000 ebx=61259000 ecx=FFFF0000 edx=61259048 > esi=00000006 edi=0022E810 > ebp=0022DC08 esp=0022DC00 program=C:\cygwin\bin\bash.exe, pid > 2748, thread main > cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023 > Stack trace: > Frame Function Args > 0022DC08 610022AE (00000012, 00000000, 0022DC28, 0022E820) Unfortunately, since both bash and cygwin are stripped, this stack trace is relatively useless. cgf has been working on adding support for .dbg libraries, which can be placed separately from stripped images, to make a stack trace worthwhile. Something else you might want to try: > Problem reports: http://cygwin.com/problems.html - -- Life is short - so eat dessert first! Eric Blake ebb9 AT byu DOT net volunteer cygwin bash maintainer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+Xd784KuGfSFAYARAm/TAJ9NzQtds7gGCUnLWimsUeNYxEHBcACcCxPt /LoEaDgAqk7zoMmn1FlkBC4= =63re -----END PGP SIGNATURE----- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/