Mail Archives: cygwin/2005/08/09/23:50:18
-----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/
- Raw text -