This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygwin copy problems usb 2.0


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]