cygwin copy problems usb 2.0

[Reini Urban]

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/