X-Spam-Check-By: sourceware.org Message-ID: <44D1ABA5.6040109@x-ray.at> Date: Thu, 03 Aug 2006 09:54:13 +0200 From: Reini Urban User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.8.0.5) Gecko/20060721 SeaMonkey/1.0.3 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: cygwin copy problems usb 2.0 References: <5519828 DOT post AT talk DOT nabble DOT com> <5528112 DOT post AT talk DOT nabble DOT com> <44C91F4A DOT 8050404 AT cygwin DOT com> <20060727201931 DOT GD3409 AT trixie DOT casa DOT cgf DOT cx> <5528898 DOT post AT talk DOT nabble DOT com> <20060727211107 DOT GB4348 AT calimero DOT vinschen DOT de> <20060727220054 DOT GC6653 AT trixie DOT casa DOT cgf DOT cx> <44D13F14 DOT 2060004 AT x-ray DOT at> <20060803012756 DOT GB31994 AT trixie DOT casa DOT cgf DOT cx> In-Reply-To: <20060803012756.GB31994@trixie.casa.cgf.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 Christopher Faylor schrieb: > On Thu, Aug 03, 2006 at 02:11:00AM +0200, Reini Urban wrote: >> Christopher Faylor schrieb: >>> On Thu, Jul 27, 2006 at 11:11:07PM +0200, Corinna Vinschen wrote: >>>> On Jul 27 13:48, aldana wrote: >>>>> isn't there a possibitly that cygwin provides a quicker >>>>> cp-implementation? i mean 4 minutes for a copy of 70MB to a memstick >>>>> (instead of CopyFile() 20 sec.) is not really good performance. i >>>>> guess there is a reason for that... >>>> Right, how did you know? The reason is that cp is a portable >>>> implementation using simple reads and writes to perform the copy. >>>> There's no such thing as a CopyFile routine on POSIX systems. >>> A few weeks ago there was a guy in libc-alpha mailing list complaining >>> that glibc's API wasn't as rich and powerful as what is found on Windows. ... >> I'm really seeing the non-optimized cygwin cp behaviour causing bad >> reputation, which could be easily patched and maybe even accepted >> upstream. Who knows. Eric what do think? Would it be worthful to think >> about? > > If this is what you want then you should look into a non-cygwin > solution. There are a couple of projects which provide GNU tools for > Windows without resorting to something like the Cygwin DLL. It's not for me, I know how to call copy or xcopy or how to install mingw's cp, which doesn't help btw. It's for the project reputation. Think of buildtimes. > Also, don't you see something wrong with the mindset of "Windows Fast. > Cygwin Slow. So, must use straight Windows functions." without even > bothering to do any research into what is causing the slowness? I didn't say that and I see the same problem as you. > How do you, or anyone who cares about this know that this "problem", know that > it isn't correctable without resorting to patching cp? I have no idea, but it should be investigated. If it's just the buffer size or some waits in the driver communication. We need not to optimize away every POSIX utility with Windows API's. But for cp vs CopyFile would make sense. If we are on Windows supported Filesystems, which costs nothing to get known (we have no mount calling fs-drivers yet), why not call CopyFile() for files bigger than the buffer size? Small files would gain nothing because of the cost of path conversion. But it's really up to the coreutils maintainer or some of us to come up with a patch. -- Reini -- 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/